From: Mark Semmelmeyer [mws@ghidra] 

Sent: Tuesday, November 01 , 1 994 8:58 AM 

To: 'Jeff Marr' 

Cc: 'euterpe@ghjdra' 

Subject: 4 bit group ops 


jeffm wrote: 

> In article <199411010450 .UAA09495@aphrodite,inicrounity . coin>, 
tbr@aphrodite.raicrounity.com (Tim B. Robinson) writes: 

> > 

> > The 4 bit group arithmetic operations (gadd.4, gsub.4, gmul.4, 

> > gumul.4, gmuladd.4, gumuladd.4) will not be supported. 

> > These operations are bein eliminated in order to reduce the atom 
count 

> I > of the data path, hopefully to the point where we can make it fit. 

> l> 

> What about the other 4 bit group ops - are they supported? 

Except for GSet, they are all XLU ops and ARE supported as tbr mentioned somewhere else in 
the mail. However, dickson told me that the 6Set.4's are gone, and I made them illegal. 
Also note that EGFMul54 is not supported and illegal. 

I just discovered that I failed to make the GMulAdd cases illegal, but they would not give 
correct answeres if you try them. 
I will fix that soon. 
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From: Geert Rosseel [geert@rhea] 

Sent: Tuesday, November 01 , 1 994 9:53 AM 

To: 'geerti^rhea' 

Subject: pager log message 


page from geert to geert; 

pageme gmake gards /geert_euterpe- iter .gplace . lis start:Nov_01_06 :47 end: 
Nov 01 06:51 exit 1 
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From: Lisa Robinson [lisar@polyhynrinia] 

Sent: Tuesday, November 01 , 1 994 3:16 PM 

To: 'craig@polyhymnia'; 'lisar@polyhymnia' 

Subject: Registered copy generated 


Copy created by: lisar 

Copy created at: Tue Nov 1 12:15:51 PST 1994 

Copy number; 278 

Copy registered to: Doug Artman 

Input file: 

/u/craig/documents/Terpsichore/Terpsichore .macps .gz.des 

Output file: /u/craig/documents/Terpsichore/Terpsichore . ps 

Printed to: rsh plotter Ipr -PCraig 

Recorded in file: /u/craig/documents/RegistrationLog 

[This message generated by /u/craig/bin/macpstops] 
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From: 
Sent: 
To: 


sysadm@gaea on behalf of Jeff Marr [jefFm@microunity.com] 

Tuesday, November 01 , 1994 4:09 PM 

'euterpe@gaea' 


In article <199411010450 .UAA09495@aphrodite .microunity. coTn>, 
tbr@aphrodite .microunity . com (Tim B. Robinson) writes: 
> 

> The 4 bit group arithmetic operations (gadd.4, gsub.4, gmul.4, 

> gumul.4, gmuladd.4, gumuladd.4) will not be supported. 

> These operations are bein eliminated in order to reduce the atom 

> count of the data path, hopefully to the point where we can make it fit. 


what eibout the other 4 bit group ops - are they supported? 
Jeff "You never snore in f reef all." Marr 
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From: Lisa Robinson [lisar@polyhymniaj 

Sent: Tuesday, November 01 , 1 994 4:1 7 PM 

To: 'craig@polyliymnia'; 'ljsar@polyhymnia' 

Subject: Registered copy generated 


Copy created by: lisar 

Copy created at: Tue Nov 1 13:16:45 PST 1994 

Copy number: 279 

Copy regist:ered to: Ronald Hunt 

Input file: 

/u/craig/ documents/Terpsichore/Terpsichore . macps . gz . des 

Output file: /u/craig/documents/Terpsichore/Terpsichore .ps 

Printed to: rsh plotter Ipr -PCraig 

Recorded in file: /u/craig/documents/RegistrationLog 

[This message generated by /u/craig/bin/macpstops] 
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From: Lisa Robinson [lisar@polyhymnia] 

Sent: Tuesday, November 01,1 994 4:27 PM 

To: 'craig@polyhymnia'; 'lisarigpolyhymnia' 

Subject: Registered copy generated 


Copy created by: lisar 

Copy created at: Tue Nov 1 13:27:04 PST 1994 

Copy number: 2 80 

Copy registered to: Larry Yamano 

Input file: 

/u/craig/docuinents/Terpsichore/Terpsichore .macps . gz ,des 

Output file: /u/craig/docuraents/Terpsichore/Terpsichore .ps 

Printed to: rsh plotter Ipr -PCraig 

Recorded in file: /u/craig/docuraents/RegistrationLog 

[This message generated by /u/craig/bin/macpstops] 
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From: Tom Laidig [tom@clio] 

Sent: Tuesday, November 01 , 1 994 4:52 PM 

To: Tim B. Robinson' 

Subject: Re: mnemo and pandora 

Tim B. Robinson writes: 


jTom Laidig wrote (on Sat Oct 22): 

I Tim B. Robinson writes: 

I I 

I jDo you know if mail to these aliases ends up in a news group (like for 

I jeuterpe)? (I'm not a news reader, so I'm not sure how to check). I 

I jhad asked for it to be set up that way, but a glance at the 

I jetc/aliases file leads me to suspect it may not be the case. If not, 

I jean you get it fixed please? 

I For mnemo checkins, I decided to reuse the muse.checkins.mnemosyne news 

I group. 

I The pandora checkins are going into muse.checkins.misc (as are a lot of 

I other things — we haven't created any new groups for quite a while). 

[Actually, 1 wasn't referring to the checkins. If I under stand it 
jcorrectly, 'mail euterpe' results in something permanently logged in 
jmuse.euterpe or some such. That's what I'd like to be happening for 
jthe mnemo and pandora aliases. I'd asked ken to set it up that way, 
|but I wasn't sure if it had happened. 

Sorry, just ran across this message lying under a rock, metaphorically 
speaking. It looks as if mail to 'pandora' goes to the news group 
muse.pandora. However, mail to 'mnemo' doesn't appear to be saved 
anywhere. 


TomL 
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From: Tim B. Robinson [lbr@aplirodite] 

Sent: Tuesday, November 01, 1994 4:57 PIVi 

To: 'hestia@aphrodite' 

Cc: 'noel@aphrodite'; 'arya@aphrodjte'; 'rich@aphrodite'; 'yves@aplirodite'; 'albers@aplirodite'; 

'woody@aphrodite' 
Subject: Netlist meeting notes 


The phone/ audio and video sections are complete and approved by the designers. 

We are waiting for the final footprint and pinnout of the second rev of the bandsplit 
filter board, final placement of the contingency VCO blocks, power plane distributions, 
and divisions of the RF ground plane. 

Actions: arya to provide final bandsplit definition by Tuesday lunch, 
noel/rich to resolve remaining VCO interaction issues, 
yves/arya to document power planes per last week's meeting, 
arya to specify required RF plane splits. 

We need another ECO to pick up the changes for the fan power and front panel connector 
resulting from the top /bottom fan change 

Action: woody/albers read in the ECO 


We need a definition of the fannout pattern for the 4 OA power connections to the DC/DC 
module 

Action: noel to define and call meeting Wednesday to finalize ground planes. 
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From: 
Sent: 
To: 

Subject: 


lisa 

Tuesday, November 01, 1994 5:19 PM 
'software-checkins-disf 
gnu-tools/si m/terp trace_types.h 


update of /p/cvsroot/gnu-tools/sim/terp 

In directory calliope : /N/auspex/root/s6/lisa/src/gnu-tools/sim/terp 

Modified Files: 

trace_types . h 
Log Message: 

Added a register -commit trace structure to the union. 
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From: Jeff Marr [jeffm@ares] 

Sent: Tuesday, November 01 , 1994 5:31 PM 

To: 'euterpe@ares' 

Subject: meltdown inhibit and power on default bypass 


Are the meltdown inhibit and power on default bypass signals into euterpe going to be 
available on pins in the packaged chip, or will they just be used for wafer test? 

where should their function be documented? 

jef fra 
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From: Chris Michael [inichael@ares] 

Sent: Tuesday, November 01, 1994 6:05 PM 

To: 'euterpe@ares' 

Subject: CSM models 


Design Folks, 


New models have been checked- in for our chosen CMOS foundry, CSM. 
The path to the HSPICE model library is: 

.lib ' /u/chip/technology/csm/hspice/models . lib ' csm_60 


The model library was constructed to make simulations using these CMOS models as 
transparent to the user as possible. The same flavors of MOS models (NS, PS, N, P, ...} 
and diode models (dwell, dsub, DW2SUBmodel) are available in the csm library as in the 
mobi library. The parameters, Nspeed and Pspeed, are still used to check MOS device 
corners . 


Some information on the models : 


MOS: CSM has provided HSPICE level 28 models for NMOS and PMOS 
transistors with minimum dimensions of W/L = 1.2/0.6 urn. 
Level 28, a Meta Software modification of BSIMl, should 
be adequate for both digital and analog device modeling. 
MOS models are separated into 16 different device ranges, 
with boundaries at W = 1,2, 7.5, and 15 urn and L = 0.6, 
0.75, and 7.5 um. E3cpect some discontinuities at these 
boundary device sizes . 

* default channel length is 0 . 6uTn 

* default drain/ source junction perimeters are: 

ps=' (w+1. 6u) * (2-shrs) ' 

* default drain/ source junction areas are: 

as=' (w*l. 6u) * (1-0 . 5*shrs) ' 

* shrd/shrs parameters are still available provided 
default junction perimeters and areas are used. 

Diodes: The library contains three diode models - DW2SUBmodel 
(NWell/Sub) , dwell (P+/NWell) , and dsub (N+/Sub) . 
* default junction width for dwell and dsub is 1.6um. 

Resistors: The following layer resistance models are included: 

* ndif - N+ diffusion 

* pdif - P+ diffusion 

* npoly - silicided N+ poly (2nd poly) 

* ppoly - silicided P+ poly (2nd poly) 

* plf - first layer routing poly 

* nw - N-Well 

* metall - first layer metal 

* metal2 - second layer metal 


Capacitors: No model for the linear capacitor was provided. Models 

for the following parasitic capacitors are included in the 
library: 

* cmlact - Ml on active 

* cmlpl - Ml to polyl 

* cmlf - Ml on field 

* cra2ml - M2 to Ml 

* cra2f - M2 on field 

* cplf - polyl on field 


wires: Wire models for Ml (wiremetall) , M2 (wireraetal2) , and 
polyl (wireplf) are in the library. 

* default wire dimensions for metal layers is w^CSum, l=10um 

* default wire dimensions for poly layer is w=0.6um, l=lOum 


Exhibit C8 


Page 11 of 598 


Changes will be made to existing models as more information is provided by 
always, comments /suggestions are welcome. 

Chris 
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From: Tom Vo [vo@nnerope] 

Sent: Tuesday, November 01 , 1 994 6:53 PM 

To: 'Tim B. Robinson'; 'Lisa Robinson'; 'Geert Rosseel'; 'Dave Van't Hof ; 'Mark Hofmann'; 'John 

Campbell'; 'B. P. Wong' 
Subject: power pads on euterpe 


There may be a real problem with the current power pad assignment on euterpe . Can we talk 
about it in the 9:30 Wed meeting ? 

tvo 
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From: Geert Rosseel [geert@ambiorix] 
Sent: Tuesday, November 01, 1994 7:51 PM 

To: 'bpw@merope'; 'geert@merope'; 'hopper@merope'; 'lisar@merop6'; 'solo@merope'; 'tbr@merope'; 
Vanthofi^merope'; Vo@meFope' 

Subject: Re: power pads on euterpe 

Tomorrow morning is the Creole REview. Let's meet in the afternoon, this is urgent. 

Meeting : Wednesday 3:00 p.m. 
Hardware conference room 

Topic : power pad assignment : do we have a problem powering up the 
TTTL I/O's ( in normal operation ) 

Geert 
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From: Fred Obermeier [fwo@pelagon] 

Sent: Tuesday, November 01 , 1 994 8: 1 3 PM 

To: 'geert@pelagon' 

Cc: 'bpwOpelagon'; 'fwo@pelagon'; 'stick@pelagon' 

Subject: vref_942ph and vref_943ph 


Geert , 

As per the Cayn meeting, we've decided to remove the rule: 

vref *_*942p*h* vref_ab943phvwy reference 
However, I cannot remove this rule from the csyn. signames file until bpw/stick's cells are 
fixed. Euterpe has both vref__942ph and vref_943ph. 

Thanks, 
Fred. 
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Sent: 

To: 

Cc: 


From: 


Bruce Bateman [stlck@kephalos] 
Tuesday, November 01, 1994 8:18 PM 


Subject: 


'geert@pelagon'; 'fwo@pelagon' 
'bpw@pelagon'; 'stick@pelagon' 
Re: vref_942ph and vref_943ph 


> Date: Tue, 1 Nov 1994 17:12:41 -0800 

> From: fwoOpelagon (Fred Obermeier) 

> To: geert®pelagon 

> Subject: vref_942ph and vref_943ph 

> Cc: bpwOpelagon, fwo®pelagon, stick®pelagoii 

> 

> Geert, 
> 

> As per the Csyn meeting, we've decided to remove the rule: 

> vref *_*942p*h* vref_ab943phvwy reference 

> However, I cannot remove this rule from the csyn. signames file until 

> bpw/ stick's cells are fixed. Euterpe has both vref_942ph and 

> vref_943ph. 
> 

> Thanks, 

> Fred. 


what do you mean by fixed? (change vref_942ph to vref_943ph?) 
What cells need to be fixed? (all cache?) 
Who is going to do this? (bp and myself?) 


BB 
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From: Fred Obermeier [iwo@pelagon] 

Sent: Tuesday, November 01, 1994 8:23 PM 

To: 'two@pelagon'; 'geert@pelagon' 

Cc: 'bpw@pelagon'; 'stick@pelagon' 

Subject: Re: vref_942ph and vref_943ph 


Hi all. 

Looks like my grep was wrong. There is no 'vref*943p' signal in tbr_euterpe-passl . spivs . 

Sorry, 

Nevermind, 

Fred, 
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From: 
Sent: 
To: 

Subject: 


Tim B. Robinson [tbr@aphroclite] 

Wednesday, November 02. 1994 12:53 AM 

*euterpe@aphrodite' 

FINAL DECISION: 4blt add/mpy/set 


tbr wrote (on Mon Oct 31) : 


The 4 bit group arithmetic operations (gadd.4, gsub,4, gmul.4, 
guinul.4, gmuladd.4, gumuladd.4) will not be supported. 

These operations are being eliminated in order to reduce the atom count 
of the data path, hopefully to the point where we can make it f it . 


This posting omitted to say that we are also not supporting the 4 bit group set 
instructions gsetl.4, gsetge.4, gsete.4, gsetne.4, gsetul.4, and gsetuge.4. 


Tim 
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Sent: 

To: 

Cc: 


From: 


Tim B. Robinson [tbr@aphrodite] 
Wednesday, November 02, 1994 1:04 AM 
'Jeff Marr' 
'euterpe@gaea' 


Jeff Marr wrote (on Tue Nov l) : 

In article <19 9411010450 .UAAO 94 95@aphrodite. microimity. com>, 
tbr@aphrodite.microunity. com (Tim B. Robinson) writes: 

> 

> The 4 bit group arithmetic operations (gadd.4, gsub.4, gmul.4, 

> gumul.4, gniuladd.4, gumuladd.4) will not be supported. 

> These operations are bein eliminated in order to reduce the atom count 

> of the data path, hopefully to the point where we can make it fit. 


What about the other 4 bit group ops - are they supported? 

I just sent a correction of the posting. The gset.4 class are not supported. However, 
all the XLU releated ops are there in 4, 2, and 1 bit sizes. It is just the arithmetic 
related operations that we have pruned. 


Tim 
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From: 
Sent: 


tbr 


Wednesday, November 02. 1994 1:06 AM 
Tom Laidig' 

Re: mnemo and pandora 


To: 


Subject: 


Follow Up Flag: Follow up 
Flag Status: Red 

Tom Laidig wrote (on Tue Nov 1): 
Tim B. Robinson writes: 


ITom Laidig wrote (on Sat Oct 22): 

I Tim B. Robinson writes: 

I I 

I |Do you ioiow if mail to these aliases ends up in a news group (like for 

I jeuterpe)? (I'm not a news reader, so I'm not sure how to check). I 

I jhad asked for it to be set up that way, but a glance at the 

I jetc/aliases file leads me to suspect it may not be the case. If not, 

I jean you get it fixed please? 

I For mnemo checkins, I decided to reuse the muse.checkins.mnemosyne news 

I group. 

I The pandora checkins are going into muse.checkms,misc (as are a lot of 

I other things ~ we haven't created any new groups for quite a while). 

lActually, I wasn't referring to the checkins. If I under stand it 
jcorrectly, 'mail euterpe' results in something permanently logged in 
jmuse.euterpe or some such. That's what Fd like to be happening for 
jthe mnemo and pandora aliases. I'd asked ken to set it up that way, 
[but I wasn't sure if it had happened. 

Sorry, just ran across this message lying under a rock, metaphorically 
speaking. It looks as if mail to 'pandora' goes to the news group 
muse .pandora. However, mail to 'mnemo' doesn't appear to be saved 
anywhere. 

No problem, we have not lost much. Can you fix the mnemo case please? 


Tim 
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Sent: 

To: 

Cc: 


Subject: 


From: 


Tim B. Robinson [tbr@aphrodite] 
Wednesday, November 02, 1994 1:12 AM 
'Mark Semmelmeyer' 

'euterpe@ghidra'; 'bobm@aphrodite'; 'Jeff Marr* 
4 bit group ops 


Mark Semmelmeyer wrote (on Tue Nov 1) : 
jeffm wrote: 

> In article <199411010450 .UAA09495®aphrodite .raicroiinity. COm>, 
tbr@aphrodite.microunity.com (Tim B. Robinson) writes: 

> > 

> > The 4 bit group arithmetic operations (gadd.4, gsub.4, gmul.4, 

> > gumul.4, gmuladd.4, gumuladd.4) will not be supported. 

> > These operations are bein eliminated in order to reduce the atom count 

> > of the data path, hopefully to the point where we can make it fit. 

> > 

> What about the other 4 bit group ops - are they supported? 

Except for GSet, they are all XLU ops and ARE supported as tbr 
mentioned somewhere else in the mail. However, dickson 
told me that the GSet.4's are gone, and I made them illegal. 
Also note that EGPMul64 is not supported and illegal. 

I just discovered that I failed to make the GMulAdd cases 
illegal, but they would not give correct answeres if you try them. 
1 will fix that soon. 

I believe the micro-arch doc is now fully up to date on these cases. 


Tim 
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Sent: 

To: 

Cc: 


Subject: 


From: 


Tim B. Robinson [tbr@aphrodite] 
Wednesday, November 02, 1994 1:15 AM 
'Jeff Marr' 

'euterpe@ares'; 'bobm@aplirodite' 
meltdown inhibit and power on default bypass 


Jeff Marr wrote (on Tue Nov 1) : 

Are the meltdown inhibit and power on default bypass signals into 
euterpe going to be available on pins in the packaged chip, or will they 
just be used for wafer test? 

They will be on the package. 

Where should their function be documented? 
We should add something to the micro-arch doc, 
Tim 
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From: tbr 

Sent: Wednesday, November 02, 1 994 1 : 1 8 AM 

To: 'Jay Tomllnson' 

Cc: 'bobm' 

Subject: euterpe/verilog/bsrc/hc hc.V hc.h hc_cmp6.V hc_drlver.V hc_error.Veqn hc_sdecode.Veqn 

hc_tagmatch.V 

Follow Up Flag: Follow up 

Flag Status: Red 


Jay Tomlinson wrote (on Tue Nov 1): 

Update of /p/cvsroot/euterpe/verilog/bsrc/hc 

In directory mercury:/N/auspex/root/s20/woody/chip/euterpe/verilog/bsrc/hc 
Modified Files: 

hc.V hch hc_cmp6.V hc_driver.V hc_error,Veqn hc_sdecode.Veqn 
hc_tagmatch.V 

Log Message: 

Interleave channels now supported as spaces 18,20,22 (craig islikely to change 
these numbers). This has been tested in the standalone environment. I also ran a 
test at the toplevel to verify that regular operations still work. 


Please get with bob to get this documented. 
Tim 
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From: vant [vanthof@hestia] 

Sent: Wednesday, November 02, 1 994 1 :29 AM 

To: 'Tom Vo'; 'Geert Rosseel' 

Cc: 'Dave Van't Hof ; 'Mark Hofmann' 

Subject: euterpe baseplate? 


Howdy , 

I was just wondering how the baseplate fixes were coming along. I'd like to start up 
another LVS/DRC run. 

Thanks , 
Dave 

Dave Van't Hof vanthof Omicrounity . com MicroUnity Systems Engineering, 
Inc . 

"What rolls down stairs, alone or in pairs, rolls over the neighbor's dog? 

What's great for a snack and fits on your back? It's log, log, log I" 
LOG from BLAMMO! (tm) All kids love Log! ttincluce 
<8td disclaim. h> 
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Sent: 

To: 

Cc: 


Subject: 


From: 


Tom Vo [vo@merope] 

Wednesday, November 02, 1994 1:36 AM 

'vant' 

'vo@hestla'; 'geert@hestia'; 'vanthof@hestia'; 'hopper@hestia' 
Re: euterpe baseplate? 


vant wrote . . . . 


> Howdy, 

> I was just wondering how the baseplate fixes were coining along. I'd 

like 

>to start up another LVS/DRC run. 


>Dave Van't Hof vanthof@microuiiity.com MicroUnity Systems Engineering, 
Inc . 

>"What rolls down stairs, alone or in pairs, rolls over the neighbor's 

dog? 

>What's great for a snack and fits on your back? It's log, log, log!" 
>LOG from BLAMMO! (tm) All kids love Log! #incluce 
<std disclaim. h> 


We may need another round of edit to address the ttl buffer ground bounce problem . We're 
on hold with the baseplate until that gets resolved . 


> 


>Thanks , 
>Dave 


>- - 


tvo 
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Sent: 

To: 

Cc: 


Subject: 


From: 


vant [vanthof@hestia] 

Wednesday, November 02, 1994 1:47 AM 

Tom Vo' 

'Geert Rosseel'; 'Mark Hofmann'; 'Dave Van't Hof 
Re: euterpe baseplate? 


Tom Vo writes: 
> 

>vant wrote .... 
>> 

>> 

>> Howdy, 

>> I was just wondering how the baseplate fixes were coming along. I'd 
like 

>>to start up another LVS/DRC run. 


>> Thanks, 
>>Dave 
>>- - 
> 

>We may need another round of edit to address the ttl buffer groiind 
>bounce problem . We're on hold with the baseplate until that gets 
>resolved . 
> 

>tvo 


Okay, Thanks for the update. 
Dave 


Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, 
Inc . 

"What rolls down stairs, alone or in pairs, rolls over the neighbor's dog? 

What's great for a snack and fits on your back? It's log, log, logi" 
LOG from BLAMMO! (tm) All kids love Logl #incluce 
<std disclaim. h> 
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From: tbr 

Sent: Wednesday, November 02, 1 994 1 : 50 AM 

To: 'Geert Rosseel' 

Cc: 'lisar@ambiorix' 

Subject: elib in snapshot 


Follow Up Flag: Follow up 
Flag Status: Red 


Geert Rosseel wrote (on Tue Nov 1): 


Why is there no delib in the snapshot proteus ? My toplevel make wants the delib/elib.config 
file and cannot find it. 


Where are you looking? 


•@gamorra/n/auspex/s41/euterpe-snapshot/euterpe/proteiis/verilog/delib 409 % Is -Is 

;al28 


1 -rw-rw-r— 1 

chip 

140 Sep 6 16:31 ealplqh3s4x2a.v 

1 -rw-rw-r- 1 

chip 

207 Sep 6 16:31 ealporl4nf8s3x3a,v 

1 -rw-rw-r~ 1 

chip 

225 Sep 6 16:31 ealporl5nf8s3x4a.v 

1 -rw-rw-r— 1 

chip 

243 Sep 6 16:31 ealporI6nf8s3x4a,v 

1 -rw-rw-r~ I 

chip 

261 Sep 6 16:31 ealporl7nf8s3x4a.v 

1 -rw-rw-r~ 1 

chip 

172 Sep 6 16:31 eaffllx2a.v 

1 -rw-rw-r— 1 

chip 

171 Sep 6 16:31 eaffbbdhl2sl lx2a.v 

1 -rw-rw-r— ] 

chip 

170 Sep 6 16:31 eaffbdhl6sl lx2a.v 

1 -rw-rw-r~ 1 

chip 

181 Sep 6 16:31 eaffdhl6sl lx2a.v 

1 -rw-rw-r- 1 

chip 

161 Sep 6 16:31 ealdfl2s3x4a.v 

1 -rw-rw-r— 1 

chip 

161 Sep 6 16:31 ealdf24s6x4a.v 

1 -rw-rw-r-~ ] 

chip 

141 Sep 6 16:31 ealnf20s6x3a.v 

1 -rw-rw-r- 1 

chip 

142 Sep 6 16:31 eabf36sl2x3a.v 

1 -rw-rw-r— 1 

chip 

141 Sep 19 15:13 eahif36s9x4a.v 

1 -rw-rw-r- ] 

chip 

268 Sep 6 16:31 eam2fnix2a.v 

1 -rw-rw-r— ] 

chip 

277 Sep 6 16:31 eani2ffdhl6sllx2a.v 

1 -rw-rw-r— 1 

chip 

282 Sep 6 16:31 ean[ieTnalrlw6xla.v 

1 -rw-rw-r— 1 

chip 

283 Sep 6 16:31 eamemalrlwi6xla.v 

1 -rw-rw-r— ] 

chip 

284 Sep 6 16:31 eamemalrlwip6xla.v 

1 -rw-rw-r— 1 

chip 

285 Sep 6 16:31 eamemalrlwipr6xla.v 

1 -rw-rw-r— 1 

chip 

284 Sep 6 16:31 eamemalrl wir6xla.v 

1 -rw-rw-r— ] 

chip 

283 Sep 6 16:31 eamemalrlwp6xla.v 

1 -rw-rw-r- ] 

chip 

284 Sep 6 16:31 eamemalrlwpr6xla.v 

1 -rw-rw-r- 1 

chip 

283 Sep 6 16:31 eameinalrlwr6xla.v 

1 -rw-rw-r— 1 

chip 

90 Sep 6 16:31 eawwlvrefl6s2x4a.v 

1 -rw-rw-r— ] 

chip 

91 Sep 6 16:31 eawwlvref20slOxla.v 

1 -rw-rw-r— 1 

chip 

90 Sep 6 16:31 eawwlvref56s7x4a.v 

1 -rw-rw-r~ 1 

chip 

490 Sep 19 15:13 elib.config 

tbr@gamorra /n 

^auspex/s41/euterpe-snapshot/euterpe/proteus/veriiog/delib 410 % pwd 


/h/auspex/s23/euterpe-proteus-cp/verilog/delib 
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Sent: 

To: 

Cc: 


From: 


Tim B. Robinson [tbr@aphrodite] 
Wednesday, November 02, 1994 1:50 AM 


Subject: 


'Geert Rosseel' 
'lisar@ambiorix' 
elib in snapshot 


Geert Rosseel wrote (on Tue Nov 1) : 


Why is there no delib in the snapshot proteus ? My toplevel make wants the 

delib/elib.conf ig 

file and cannot find it. 

Where are you looking? 


tbr®gamorra /n/auspex/s41/euterpe-snapshot/euterpe/proteus/verilog/delib 
409 % Is -Is 
total 28 


1 

-rw- 

rw- 

r-- 

1 

chip 

140 

Sep 

6 

16 : 

; 31 

ealplqh3 s4x2a . v 

1 

-rw- 

rw- 

r-- 

1 

chip 

207 

Sep 

6 

16 : 

; 31 

ealporl4nf 8s3x3a. V 

1 

-rw- 

■rw- 

r- - 

1 

chip 

225 

Sep 

6 

16 : 

; 31 

ealporlsnf 8s3x4a . V 

1 

-rw- 

rw- 

r- - 

1 

chip 

243 

Sep 

6 

16 : 

: 31 

ealporl6nf 8s3x4a . V 

1 

-rw- 

rw- 

r- ~ 

1 

chip 

261 

Sep 

6 

16: 

;31 

ealporl7nf 8s3x4a. V 

1 

-rw- 

rw- 

r-- 

1 

chip 

172 

Sep 

6 

16: 

I 31 

eaf f llx2a.v 

1 

-rw- 

rw- 

r-- 

1 

chip 

171 

Sep 

6 

16: 

; 31 

eaffbbdhl2sllx2a.v 

1 

-rw- 

•rw- 

r- - 

1 

chip 

170 

Sep 

6 

16 ; 

; 31 

eaf fbdhl6sllx2a. V 

1 

-rw- 

rw- 

r- - 

1 

chip 

181 

Sep 

6 

16: 

: 31 

eaf f dhl6sllx2a. V 

1 

-rw- 

•rw- 

r- - 

1 

chip 

161 

Sep 

6 

16 ; 

;31 

ealdf 12s3x4a. V 

1 

-rw- 

rw- 

■r-- 

1 

chip 

161 

Sep 

6 

16; 

:31 

ealdf 24s6x4a. V 

1 

-rw- 

rw- 

■r- - 

1 

chip 

141 

Sep 

6 

16: 

:31 

ealnf 2 0s6x3a. V 

1 

-rw- 

■rw- 

r- - 

1 

chip 

142 

Sep 

6 

16; 

;31 

ealnf 3 6sl2x3a. V 

1 

-rw- 

■rw- 

r- - 

1 

chip 

141 

Sep 

19 

15; 

; 13 

ealnf 36s9x4a . V 

1 

-rw- 

■rw- 

r- - 

1 

chip 

268 

Sep 

6 

16; 

:31 

eam2f £llx2a . V 

1 

-rw- 

•rw- 

r-- 

1 

chip 

277 

Sep 

6 

16: 

:31 

eaTn2ffdhl6sllx2a.v 

1 

-rw- 

rw- 

■ r-- 

1 

chip 

282 

Sep 

6 

16: 

:31 

eamemalrlw6xla . v 

1 

-rw- 

rw- 

r- - 

1 

chip 

283 

Sep 

6 

16; 

;31 

eamemal r Iwi 6xla . v 

1 

-rw- 

■rw- 

■r- - 

1 

chip 

284 

Sep 

6 

16 ; 

;31 

eaTnemalrlwip6xla . v 

1 

-rw- 

rw- 

r- - 

1 

chip 

285 

Sep 

6 

16: 

:31 

eamemal r lwipr6xla , V 

1 

-rw- 

rw- 

r- - 

1 

chip 

284 

Sep 

6 

16: 

:31 

eamemalrlwir6xla . v 

1 

-rw- 

rw- 

r- - 

1 

chip 

283 

Sep 

6 

16: 

:31 

eamemalrlwp6xla . v 

1 

-rw- 

•rw- 

r- - 

1 

chip 

284 

Sep 

6 

16; 

;31 

eamemalrlwprexla . v 

1 

-rw- 

•rw- 

r- - 

1 

chip 

283 

Sep 

6 

16; 

; 31 

eamemalrlwr6xla . v 

1 

-rw- 

■rw- 

r- - 

1 

chip 

90 

Sep 

6 

16; 

:31 

eawwlvref 16s2x4a . v 

1 

-rw- 

rw- 

r- - 

1 

chip 

91 

Sep 

6 

16: 

:31 

eawwlvref 2 0 s 1 Oxla . v 

1 

-rw- 

•rw- 

r- - 

1 

chip 

90 

Sep 

6 

16: 

:31 

eawwlvref 5 6 s 7x4 a . v 

1 

-rw- 

•rw- 

r- - 

1 

chip 

490 

Sep 

19 

15: 

:13 

elib.conf ig 


tbrogamorra /n/auspex/s41/euterpe-snapshot/euterpe/proteus/verilog/delib 
410 % pwd 

/n/auspex/s23/euterpe-proteus-cp/verilog/delib 
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From: Geert Rosseel [geert@ambiorix] 

Sent: Wednesday, November 02, 1994 2:20 AM 

To: tbr@amblorix* 

Subject: elib : found the problem .. me not crazy, just confused. 
Hi Tim, 

I was looking in : 

/n/auspexys4 1 /euterpe-proteus/proteus 
Apparently that is different from : 

/a/auspex/s4 1 /euterpe-snapshot/euterpe/proteus 

I though that Lisa had said that these two were linked together and were the same thing 

When I do an Is in /n/au5pex/s41/euterpe-proteus/proteus/veri1og 

Iget: 

BOM Makefile dclib eclib mlib xlib zclib 

BOM.BAK cerbmaster diff.h exUb src zblib zeblib 

CVS clib dxlib libsrc wrappers zblibsrc zxlib 

NO elib or delib ... 

Geert 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Simon Crosby [Simon.Crosby@cl.cann.ac.uk] 
Wednesday, November 02, 1994 4:41 AM 
'Pearl Tsai' 
'a2x-users@x.org' 
Re: talking (the a2x faq) 


This is a good opportunity for me to post the a2x and DragonDictate 
faq which I keep. You will find lots of information on hoarseness 
with DragonDictate. 

If sending long messages like this annoys people on the list then 
please let me know. I do not intend to post the faq more than once 
per month unless there is a lot of interest. 


The (unofficial) a2x faq is available as: 

http : //www. cl . cam. ac .uk/users/sac/a2x- faq. html 

A preliminary version of the DragonDictate faq is also there: 

http: //www. cl . cam. ac .uk/user s/sac/dd- faq. html 

These are both maintained entirely by voice, so please forgive the 
poor format at present. Pearls of wisdom, hints, tips, dcoms and 
macros are all very welcome. 

Simon 

[Simon , Crosby@cl . cam . ac . uk] 

[http: //www. cl, cam, ac .uk/users/ sac/] 


The a2x FAQ 

Currently maintained by Simon Crosby entirely by voice, using 
DragonDictate and a2x. 

This FAQ contains distilled pearls of wisdom about a2x, a piece of 
public domain software designed to interface the DragonDictate speech 
recognition system on a PC to a workstation rimning the X Window 
System . 

A related FAQ, the DragonDictate FAQ contains information about 
DragonDictate and speech recognition systems for all types of 
computers, much of which is relevant to a2x, but not specific to it. 

These FAQs are direct copies (shortened where possible) of postings to 
the a2x mailing list, the SORBHAND mailing list, and the C+HEALTH 
mailing list. Send contributions/corrections/updates/ideas to me. 


Contents 

Just click on the topic you want to get to. . . 

The a2x Mailing List 
Where to get a2x 
a2x Basics 
a2x In Operation 


Simon 
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How do I build a2x ? 

What Use are DD ' s States ? 

How useful is DD / a2x for Programming ? 

Troubleshooting with DD / a2x 

Window Manager Hints 

Contributed Voice Macro Sets 

Useful DCOMS / Macros 

Useful Shell Scripts 

PC Telnet Software 

The a2x Olyiopics 


The a2x Mailing List 

A mailing list of a2x users exists, to keep people abreast of any new 
developments. The mailing list is a2x-users®expo. Ics .mit . edu; send 
requests to join to a2x-users-request®expo.lcs.mit.edu. 

Return To Contents List 


Where to get a2x 

The current version is on ftp.x.org as /contrib/a2x. tar . Z , or on the 
web here is the reference . 

Return To Contents List 


a2x Basics 

(Mostly from the a2x man page) 

a2x is designed to interface DragonDictate to the X Window System. a2x 
converts the ASCII output of DragonDictate into X device events. a2x 
is capable of manipulating both the keyboard and the pointers- 
depending on the applications, it is possible to use X hands- free 
through a2x. 

a2x requires an X protocol extension to function. The XTEST, 
DEC-XTRAP, and XTestExtensionl extensions can be used. The XTEST 
extension was developed by the X Consortium for use in the X Test 
Suite, and an R5 patch to support the XTEST extension is available via 
anonymous ftp to export.lcs.mit.edu, as the file 

/p\ib/XTEST/R5f ix-xtest-1 . The DEC-XTRAP extension was developed by 
Digital Equipment Corp., and public versions are available for both R4 
and R5. The XTEST extension has been incorporated as standard into the 
R6 server. The XTestExtensionl extension was originally developed for 
an old test suite done by an informal group known as the X Testing 
Consortium; the client-side library and some device- independent code 
exists in both the R4 and R5 core distributions, but only a couple 
sample servers (HP and X386) in the MIT distribution supports the 
extension (some product servers might though) . 

Note 

From: Adrian Nye 


> >the file /pub/XTEST/R5f ix-xtest-1 . this file no longer there -- 

> I've been searching extensively for xtest for R5 and I can't find it 

> anywhere. I've found xtest for R6 on a number of sites but no R5. 

> If anyone can point me in the right direction, I'd be very thankful. 

> Sorry if I'm being a bonehead. . . 

From: steffen@iexist.att.com Date: Fri, 9 Sep 94 11:54:47 CDT 
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I tracked this dovm yesterday, it is now /pub/R5/f ixes/f ix-18 . Z, but 
it is an optional patch and may not have been applied. Use xdpyinfo 
to get the list of extensions. 

The XTEST extension is compiled into the R6 X server by default if you 
build X from the X consortium distribution (at least on my Sun) . You 
probably already have it; use xdpyinfo to check. 


a2x was originally written for the XTEST extension, but both DEC-XTRAP 
and XTestExtensionl also work. The main difference as far as a2x is 
concerned is that XTEST permits time delays inside the X server, while 
with DEC-XTRAP and XTestExtensionl the delays are handled on the 
client side and hence can be somewhat less accurate, but time delays 
are rarely needed. In addition, XTestExtensionl does not provide a way 
to synthesize relative pointer motion, so the WarpPointer protocol 
rec[uest is used instead. 

The Imakef ile for a2x comes configured to use only XTEST, but you can 
configure it to compile in support for any or all of the extensions; 
a2x will automatically choose whichever extension is supported by the 
display. If you dynamically switch among different displays supporting 
different extensions, you will probably want to compile more than one 
extension into a2x. At the top of the Imakef ile are #define's for 
BuildWithXTest , BuildWithXTrap, and BuildWithXTestExtl; simply set the 
ones you want to YES and the ones you don't want to NO. To see which 
extensions are supported by your X server, use xdpyinfo. Your server 
must have at least one of "XTEST", "DEC-XTRAP", or "XTestExtensionl" 
in order to use a2x. 

The Imakef ile also comes configured by default to assume that 
DragonDictate version 1.01 is being used, although the actual version 
can be overridden on the a2x command line. If you normally use 
DragonDictate 1.01a or 2.0 or higher, then change the #de£ine for 
OldDragonDictate to NO before building. 

The documentation provided here is for using DragonDictate and a2x 
solely for work under X; the assumption is that you do not use 
DragonDictate with programs on the PC. If you use DragonDictate with 
programs on the PC, you may need to create doom files for switching 
between PC and X use. 

Return To Contents List 


a2x In Operation 

There are two ways to run DragonDictate: directly under DOS, and under 
DESQview/X. See the man page for more details. 

The normal mode of operation is to use a telnet program on the PC, and 
telnet across to your workstation and log in. For this you need an 
Ethernet card or similar on the PC, and a telnet program such as 
provided by PC-NFS or other products. You may wish to try using rsh 
instead of telnet, but the performance may be substantially worse. If 
you do not have a network connection, it should be possible to use a 
terminal program and log in to the workstation over a serial line, but 
performance over a serial line will likely not be as good as over a 
network. In the telnet session, run the script DragonDictate provided 
with the a2x distribution. You should be able to speak this, by saying 
"DragonDictate", " [enter\ key]", "OK" (the "OK" being necessary to pop 
down the menu to permit execution to continue) . This script simply 
clears the screen and starts up a2x. Clearing the screen is a 
convenience so that the focus of attention on the PC screen will be 
the DragonDictate menus. You can, of course, write your own script or 
simply run a2x directly. 
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a2x takes each ASCII character produced by DragonDictate and 
determines a key on the X keyboard that can be pressed and released to 
generate that character. If Shift and Control modifiers are necessary 
to generate the character, a2x will automatically press and release 
keys for those modifiers. For example, for the character 'A', a2x will 
typically have to press a Shift modifier key, press an 'a' key, 
release the 'a' key, and then release the Shift modifier key. 

It is not necessary to perform all of your "typing" through a2x; you 
can mix a2x output with direct keyboard typing and direct pointer 
manipulation. But, you should normally only switch between direct 
input and a2x input when all keys and buttons are in the released 
state, to avoid confusing a2x. (One simple exception to this rule is 
that you can use a2x to press /release buttons and keys while directly 
moving the pointer with your hand,) 

Return To Contents List 


How do I build a2x ? 


From: Tom Knotts 

> I have one general question. After downloading the a2x 

> software which compiler and which libraries do I need to 

> compile the C-code. I am trying to run a2x over an 

> X- Server, who would know anything about interfacing the Dragon 

> card to work with X. > 

First, you do 

imake -l/usr/local/lib/imake -DTOPDIR=/usr/a2x/XllR5 

This builds a makefile with /usr/a2x/XllR5 the top directory (or 
wherever you choose to put it) 

Then when you type "make" you get: 

cc -o a2x a2x.o +03 /usr/a2x/XllR5/lib/Xmu/libXrau . si -iXtst 

/usr/a2x/XllR5/extensions/lib/libXext , si 
/usr/a2x/XllR5/lib/X/libXll . si 
-L/usr/lib/XllR5 -L/usr/lib/XllR4 

-Im 

There are the libs you need. Notice /usr/lib/Xtstlib . a 
From: Simon Crosby 
Al t emat ively : 

type "xmlcmf" to make the Imakefile type "make" to make a2x easier 
this way ! 
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What Use are DD ' s States ? 
From: stef f enoiexist . att . com 

> From: doug_bernard@tmai , com (Doug Bernard) 

> I've read a2x.ms. One of my questions is whether I can command 

> DragonDictate to switch between multiple user-defined 

> dictionaries- For example I'd like to set up the following 

> dictionaries (invoked by the voice commands shown in quotes) : 1) 
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> "UNIX" i.e. command line strings, including predefined aliases 

> (of which I already use about 250) 2) "VI" i.e. mnemonics for vi 

> commands 3) "CHAR" i.e. mnemonics for single characters, with 

> u.c. and I.e. subdictionaries 4) "WORD" i.e. DD ' s real- life 

> dictionary 5) "C- PLUS- PLUS" for C++ keywords 6) "User-App-n" for 

> keywords in the user's app 7) "MOUSE" to move and click the mouse 

> etc. > The main point is that for me, by having a personal, 

> structured user dictionary, I organize my thought processes 

> better, reduce the complexity of individual mnemonics, and have 

> fast look-up times. You can do this but I don't recommend it as 

> it seems to be a style carried over from a limited voice 

> recognition system like Saylt or Voice Navigator that had such 

> poor recognition you had to limit the active dictionary to around 

> 50 words. With DragonDictate you just use naming convictions for 

> voice macros, e.g. "go" to move the mouse and "move" to move the 

> cursor. You will find you want to switch the above dictionaries 

> every few utterances once you have control of multiple windows. 

> I have over 600 voice macros and less then 3% misrecognitions or 

> about 1 in 35 utterances. With a limited system like the 

> Macintosh Voice Navigator I gave up as it was extremely limited 

> in power, took too much time to program, and seemed to 

> misunderstand or not hear at least a quarter of my utterances. 

You may also find it easier to say commands as words than the aliases 
you have defined, e.g. I removed all my single letter aliases for UNIX 
commands like find and make. 

From: craig@mneraosyne . MicroUnity , com (Craig Hansen) 

I'm a Kurzweil VOICE user, which supports multiple user-defined 
dictionaries, amd I, too prefer using a single, large dictionary. In 
fact, I added vocabulary elements to permit spelling out single 
characters without changing mode. The problem is that without a 
mechanism to keep the mode in line with your current application, 
having multiple modes (dictionaries) is a source of errors, resulting 
from having the recognizer use the wrong dictionaiy. 


From: dana®sybase . com (Dana Bergen) 

I thought I was going to want to set up a lot of state vocabularies, 
but found it unnecessary. I'm finding that it works fine to have 
almost everything in the global vocabulary, and it saves the hassle of 
switching and keeping track of which one you're in. I have Unix, vi, 
mail, and window management commands all in my global vocabulary. I 
created a state vocabulary for using Frame, which suits the way I 
work; I switch around frequently between using Unix/vi/mail commands, 
but when I'm using Frame I'm usually using it for a while, so saying 
"use frame" when I start and "exit state" when I stop is not a big 
burden. It also lets me use commands like "page up" and "page down" 
and have them do the right thing whether I ■ m in Frame or vi . 

From; Jack 

I do almost exactly the same thing except that I immediately enter a 
state called "Unix" and stay there. There are certain Dragon 
functions that tend to kick you out of the state you are in and put 
you back in the global state (I forget their exact terminology) . I 
just added dcom code to the commands that do that so that the last 
thing they do is to reenter the "Unix" state. I use emacs as an 
editor, so I can use the exact same macro for both emacs and frame. 
Since a number of editors have adopted emacs -like metaphors, I can 
(and do) use them all with the same macro for various basic emacs 
functionality. . . this works extremely well for me and I rarely have to 
think about voice recognition, I just use it, a case where ignorance 
truly is bliss . . . 
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How useful is DD / a2x for Programming ? 


This is a summary from a request for support by Doug Evans, who needed 
help to persuade his company to spring for a DD setup. Shows that it 
works . 


From: Doug Evans 

This is way cool. Thanks for the replies. I took out the author's 
names. I think enough replies went to the list anyway. 


I am an engineer and a DragonDictate user for 18 months. I do a lot 
of 

writing using Latex and Framemaker and some software (VHDL) 
development 

using eraacs. DragonDictate works extremely well for the writing. 
Code 

development is not as easy but still works. I use DragonDictate for 
virtually all my computer input, I am a UNIX user and use a2x. I 
use 

DragonDictate 4-5 hours per day easily, which was about ray level 
before 

I got RSI. My doctor does not expect I will ever be able to use a 
keyboard extensively again. DragonDictate costs $1K for the classic 
version. That is peanuts. That is probably one day of work lost. 
Any 

management type who can't figure that out is an idiot. I could not 
work without DragonDictate, and I wrote some proposals this year 
which 

brought in almost $2M of revenue. The choice is easy. 


I am such a programmer, I am doing WWW development in C++ and other 
languages. I use DragonDictate and believe it has saved ray career, 
your managers are full of it and I am proof. So there! 


I use DragonDictate in combination with the freeware package a2x to 
program on a fulltime basis in the unix environment under X. 

I never type . 

I get about 20-40 words per minute input speed using DragonDictate. 
the range is so large because DragonDictate ' s comprehension really 
depends on whether it has heard you say a word before. I have been 
using it for six months, but will still occasionally run into 
stretches where I am using a let of new jargon, and then I am 
frequently forced to correct DragonDictate • s interpretation of what 
I'm saying. 

My time is split into equal thirds devoted to C programming. Bourne 
shell and lisp programming. 

I think it is an acceptable solution, and c[uite cheap considering what 
you get. In my case, it may have saved me from having to change 
careers due to my hand problems. 


I'm a Senior Software Engineer at XXX. I investigate problems, write 
specifications documents, write code, and fix bugs. My work is in C 
in a Unix environment . 
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I use DragonDictate all day long. I can't type at all without pain, 
so I do everything with DragonDictate. I think that the effect on my 
programming productivity is minimal; i.e. I get pretty much the same 
amount of work done with DragonDictate as I used to get done typing. 
It's a little more of an impediment when writing a document; I create 
documents somewhat more slowly than before. However, I'm perfectly 
capable of doing what's needed for my job. I was a very fast typist; 
DragonDictate makes me more like a fairly slow typist . There are 
plenty of engineers here who are not super fast typists who do a good 
job. My company expects the same amount of work from me that they 
expect from other people, and this has not been a problem. 

There was a pretty significant amount of time required to get going 
with DragonDictate in a Unix programming environment . Getting the 
various pieces of software and hardware working together correctly 
took some doing; getting macros and such set up took some doing; 
getting used to using DragonDictate took some doing. I spent a fair 
amount of time after hours working on my environment for the first 
month or so. During that period of time, I was doing my job using 
DragonDictate but wasn't as productive as I am now with it. 


I use DragonDictate for all of my programming except assembler, which 
is a bit of a syntactical nightmare. Programming is easiest if you 

1 . Have a set of macros in DragonDictate which assist you in 
programming and 2. Have a customized editor with intelligence about 
what you are trying to do. I use emacs, and have written several 
(admittedly crude) emacs lisp functions which handle all of the syntax 
of C programming. 

Let me give you an example: 

I say "c-for-loop" and what I get in my emacs buffer, correctly 
indented to preserve the logical structure of the current program is: 

I 

\ / 

V £or(;;) { 

} 

The arrow ending in 'v' above indicates where my cursor ends up, so 
that I can insert the first argument of the for loop. I have similar 
functions for all of the C structures and sub- structures . I also have 
words such as int, char, struct etc. which are commonly used. I can 
also comment out regions of code, where a region is a logical block, 
such as a function or whatever, and use blocks in movement commands 
such as "right- conditional" which steps right over the next 
conditional block. 

If you are editing somebody else's code and they tend to use ghastly 
variable names such as Ikjdsf Ikjdf sa, this could be a problem, but 
here again emacs comes to the rescue. In this case I say "lima kilo 
dabbrev- expand" and emacs tries to expand something which begins with 
the letters "Ik", by looking back up the file. I'm no great lisp 
hacker, and I've promised myself that I will sit down one day and get 
this thing really sorted out ( more intelligent) , but it works well 
enough that I have managed to put that day off thus far. 

As I've stated before on this list, I would be happy (in the spirit of 
a2x cutid emacs, which are publicly available) to provide my 
DragonDictate macros amd emacs lisp code to anybody who wants it. I 
would hope that they could be improved by somebody with a bit more 
time and creativity, and again made public for general benefit. 

Best of luck and I hope this will help persuade your boss that you 
will be better off with DragonDictate. 
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I use DragonDictate for practically all of my programming (c, C++, 
shell), documentation (latex), and email. I have been using it 
"full-time" since January 1991. Without it I would not be able to 
work and would need to find another profession. 

Emphasize to your employer that carpel tunnel syndrome involves 
serious, permanent nerve damage. A complete dragon based environment 
can be assembled for under $4000, perhaps under $3000. Your employer 
will find this to be a lot cheaper than the costs of worker ' s 
compensation and long terra disability which they will incur if they 
push you to keep working in a way that you know will injure you. 

Lastly^ I would encourage the individual to purchase their own system, 
if they are able. I own my recognition system and am happy with the 
decision to buy it myself. I'm too dependant on it. . . it would be 
like someone else owning my fingers . 


I do R&D [...] at XXX. I just wrote a 700 line C language program on 
UNIX in a few weeks, and I'm continually changing a large HyperCard 
application on a Macintosh. In a few months I expect to be 
programming on a PC in visual Basic and ToolBook. I use DragonDictate 
all day with up to 3500 utterances/day with less than 3% errors. I 
can dictate as fast as I could type, although it took 6 months and 
writing 700 voice commands to become that proficient. Here is the 
standard blurb I post to our internal netnews: 

I've been unable to type or use a pointing device for more than a few 
minutes since my Repetitive Strain Injuries became severe in March 
1993 . Permanent continuous pain and partial loss of the use of my 
hands was becoming likely due to permanent nerve damage if I continued 
typing, so I stopped. Since then I have assembled a voice- controlled 
computing environment on a PC, UNIX workstation, and Macintosh. 

I've evaluated and assembled many pieces of software and hardware and 
written hundreds of voice commands to integrate them. I'm using the 
DragonDictate Classic speech recognition product running on a PC 
connected to the a2x program controlling the X Window System running 
on a Sun workstation. This allows me to enter and edit text and tJNIX 
commands and control the (mouse) pointer by voice. I also control a 
Macintosh by displaying its screen on the Sun workstation using 
InterCon ' s Planet X software . You can use a simpler version of this 
system if you just use a PC, or if you use a mainframe but can login 
from a PC. The cost of the basic system (DragonDictate Starter at 
$695 plus a 486/33MHZ PC with 8M memory) is about $2700. It takes a 
few weeks to get comfortable using it; after 6 months I could dictate 
as fast as I could compose text and as fast as I used to be able to 
type, about 15 words /minute. 

My main uses of this voice- controlled computing environment have been 
word processing, email, C and HyperCard programming, and gathering 
information from our library, Usenet, and CD-ROM and Internet 
databases, I can do everything by voice that I used to do with a 
mouse and keyboard. 


Due to a chronic RSI, I have been using DragonDictate for over 3 years 
to do software development in C/C++ on the following platforms: 
DECwindows /Motif on VMS, Motif on Unix (a little), and DOS/MS Windows. 
I feel that DragonDictate allows me to be approximately as productive 
as I was when I was typing. By this I mean that although some tasks 
take a little longer, other tests are actually easier using 
DragonDictate, and in the long run it more or less evens out. 

I am extremely satisfied with DragonDictate, Without this product, I 
doubt whether I would be able to continue in my career as a software 
engineer . 
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Return To Contents List 


Troubleshooting with DD / a2x 


People frequently have problems with the undo facility of a2x. Here 
is a sample of postings. 

From: Bob Scheifler 

how do you represent a 

key such as Escape or Tab as a key in the ? 

You can actually put control characters directly in the file, but it's 
probably easier to use followed by a character. The usual 
convention is followed of using the character you get by adding 0x100 
to the control character . E.g./ 

^@ NUL TAB *J LF *M CR * [ ESC 

And one special case: 
^? Delete 

Date: Thu, 30 Dec 93 17:59:58 CST From: stef f en®iexist .att . com 

How can I use the a2x undo facility for the [back" 1] macro? I have it 
defined as 

add-word /t "[back 1]" "{Del}" invisible 
for a2x. I tried changing it to 

add-word /t "[back 1]" " {ctrl+t} {Ctrl+c}?" invisible 

but it inserts •?' instead of deleting the previous character when I 
use it. 

P.S. I'm working on a complete .a2x undo file for emacs macros and am 
using the DragonDictate 2.0 macro state facility to keep the a2x 
undoable emacs macros local and the regular emacs voice macros global 
because I occasionally use emacs outside a2x or in DOS. 

Date: Fri, 31 Dec 1993 12:16:14 EST From: Bob Scheifler 

I tried changing it to 

add-word /t "[back 1]" " {ctrl+t } {Ctrl+c} ? " invisible 
but it inserts • ? ' instead of deleting the previous character when 
I use it . 

Right, because { Ctrl+t }{ Ctrl+c} means "turn on the X Control 
modifier", it doesn't mean "make an ASCII control character". So, if 
you have a key on your X keyboard with '/' in the unshifted position 
and '?' in the shifted position, what a2x generates is em event for 
that key that has the X Shift and Control modifiers turned on. 

The reason you can't just use {Del} for your purpose is that 
DragonDictate won't generate a backspace for it, so a2x won't see it 
to undo it. So what you need to do is specify, by keysym, the key you 
want to press. Assuming that key is labeled Delete, you can use 

(Ctrl+t }Delete{Ctrl+t} 

That's a bit long, so you can also do it by hexadecimal keysym value: 
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{Ctrl+t}ffff {Ctrl+t} 

That's still a bit long, but I can't think of a shorter way to do it 
without adding something to a2x. 

To make sure the key is labeled Delete on your keyboard, use xev to 
see what key is pressed when you send {Del} through a2x. 

Now, to \mdo that (using the emacs undo command) , you can put 

''TDelete*T:*_ *Tffff*T:*_ 

in your .a2x file. 

Subject: help with undo? Prom: D! 

in response to my previous questions, a number of people explained 
.a2x files to me as a way to do undos . However I can't get them to 
work at all I Can someone help me? Here is an example: 

I have macro [click 1] assigned to 

{Ctrl+t} {Ctrl+b}l{Ctrl+t} {Ctrl+t } {Ctrl+b} l{ctrl+t } 

in my .a2x file I have the following line: ^T^Bl'^T'^T^Bl^T : 

I thought that would make the "undo" for [click 1] a no-op. But when 
I say "scratch that" after a [click 1] , I get 6 backspaces instead. 

What am I doing wrong? 

I am using DragonDictate V3.0. Maybe my version of a2x doesn't were 
with DragonDictate V3.0? I think I have a2x version 1.12. 

From: steffen@iexist.att.com Subject: Re: help with undo? 

As you discovered, telnet usually swaps backspace and delete by 
default. For PC-NFS use the -y option, for other software check the 
manual . 

Also you need the latest a2x that was updated at the end of last year. 
The first line of a2x.c should be 

/* $XConsortium: a2x,c,v 1.129 93/12/29 20:15:28 rws Exp $ */ 


From: dana@sybase.com (Dana Bergen) Subject: Re: DESQview/X 2 

>Has anyone had success using any version of DragonDictate with the 
newest >version of DESQview/X? Hints would be appreciated. Thanks. 

I'm using DragonDictate 3.0 with DESQview/x version 2. This is the 
only configuration I've used, so I ceui't tell you what is different 
from previous versions. I'm using the PC network software that comes 
with DESQview/X 2. I haven't had any of the hanging/crashing type 
problems that people have apparently had with some combinations. I 
have encountered the following two problems with the interaction of 
the two packages: 

I had to get rid of the dragon logo that is displayed at startup of 
DragonDictate 3.0 because it hung my remote DESQview/X window. (Delete 
the file dd.bit . ) 

Old menus hang around on the DESQview/X window on my workstation. 
This is really annoying because sometimes it's not obvious whether 
what's up there is "real" or not. I've corresponded with both Dragon 
and Quarterdeck but no one seems to have solved this. 

From: doug_bernard@tmai.com (Doug Bernard) Subject: Re: demise of DD 
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hotkey in telnet session 


This is a dcora entry that preserves the DragonDictate hotkey in the 
telnet session (thanks to Jack for the tip on the kbh (keyboard 
handler) command) : 

; "[start UNIX]": ; telnet to cougar; pause; login as dougb; pause 

; . . start a2x ; . . remove DD choice list via dkey {Enter} ; 

. . call- to- state a2x (do last because takes some time to switch) 

add-word /t /g "[start UNIX]" "telnet cougar {Enter } {Doom }pause 

4000{Dcom} {Alt+c}kbh of f {Enter }user {Enter} {Dcom}pause 

200 {Dcom}password {Enter} {Dcom}pause 

6000 {Doom} DragonDictate {Enter} {Dcom}dkey 

{Enter} {Dcora} {Dcom}call- to-state \"a2x\" {Dcora} " i 

I also use the following to quit: 

; "[quit UNIX]": this will work whether or not a2x is running: ; 

. . exit a2x via ^t^e; hit enter key (in case a2x not running) ; pause 

for a2x to exit ; .. logout of remote host; pause; exit telnet; pause 

; . . remove DD choice list via dkey {Enter} ; . , return to state 

preceeding a2x (do last because takes some time to switch) add-word /t 

" [quit UNIX] " " {Ctrl+t} {Ctrl+e} {Enter } {Dcom}pause 

1000 {Doom} logout {Enter} {Dcom}pause 3 000 {Dcora} {Alt+x} {Doom} dkey 

{Enter} {Dcom} {Dcom} return {Doom} " invisilole 

Here is another problem -- the automatic capitalization of words by 
DragonDictate at the end of a sentence can cause problems with the 
control sequences embedded in your DragonDictate/a2x macros: 

From: steffen@iexist.att.com Subject: Re: problem with vs '^t 

From : carroll@zko . dec . com 

my a2x session keeps getting screwed up, and I finally figured out 
why. Apparently, a2x does not consider CTRL+T the same as CTRL+t ! 
therefore, when I do something which causes the next character to 

be 

capitalized (such as "period", [capitalize word], [begin 

uppercase] , 

[shift-key] , etc) , and then say a macro of the form 
CTRL+t CTRL+t, (such as [click 1] ) , it gets screwed up 
because it doesn't pick up the first *T. 

The only fix I have foimd for this is to change my macros to 

things 
like 

*■ {dcom} lowercase -word{ dcom} {Ctrl+t } {normal-case}Delete{Ctrl+t } . 

(The {normal-case} is necessary because "Delete" *must* be 
capitalized 

for the XServer to recognize it.) 

Get rid of the sentence- ending punctuation capitalization it is an 
endless source of errors . Here are DragonDictate 3 . 0 commands to do 
it and define begin sentence and paragraph beginning macros, so you 
get capitalization only when you want it: 

; don't capitalize after sentence -ending punctuation characters ; 
note : these lines cause an error in DragonDictate 2 . 0 punctuate 
". \"period\'"' left punctuate "? \ "question mark\"" left punctuate "I 
\ "exclamation point\"" left 

; use these macros instead add-word /g /t " [begin paragraph]" "" c 1 r 
add-word /g /t " [begin sentence] " " " c 1 r 

From; dana®sybase , com (Dana Bergen) S\abject: Re: problem with *T vs "^t 

>; don't capitalize after sentence -ending punctuation characters >; 
note: these lines cause an error in DragonDictate 2.0 >punctuate 
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". \"periocl\"" left >punctuate "? X^question mark\"" left >punctuate 

"! \"exclamation point\"" left 

I like having these available, so I have a second set of macros that 
don't punctuate "dot", "hook mark", and "bang" (actually "dot" is 
already built in) -- which I use when I'm not about to dictate another 

sentence. Between these and having added the lowercase-word dcom to 
my escape key macro (for using with vi) , I've generally eliminated the 
problem. I think which approach is best depends on what kinds of 
things you do. 
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Window Manager Hints 


From: steffen@iexist.att.com Subject: .twmrc for [doit] and others 

It took me considerable effort to duplicate the .twmrc lines for a2x 
window management voice macros: 

"F3" = cjm|s ; w|t|i|f : f . delete Buttonl = c|m|s : w|t|i|f|r : f.menu 
"defops" Buttonl = m : wjtjilf : f . raise Button2 = m : wjtjilf : 
f. lower Button2 = c|m : w|t|i|f : f .iconify Buttons - m : w|t|i|f : 
f . move 

but I " m unsure what Execute and KP_F1 to 3 are supposed to do and how 
to define them. It would be good to put all these in an add2 . twmrc 
file in the a2x distribution. 

From: Bob Scheifler 

It took me considerable effort to duplicate the . twmrc lines for 

a2x 

window management voice macros : 

They were really only intended as examples of writing macros, not as 
something that I expected everyone to use, 

but I'm unsure what Execute and KP_F1 to 3 are supposed to do and 
how to 

define them. 

In miy personal environment, I have customized various programs so that 
saying "[doit]" does something similar in most windows. At the time I 
wrote the documentation, I had " [doit] " press the key labeled Execute. 
Since then I've changed it to press the function key labeled F8. In 
my X resources, I have for example: 

Xrah* tocMenu . Accelerators : #overr ide\n\ 

! : F8 : XmhCommit Changes ( ) \n\ 


so that " [doit] " in the main xmh window commits ray folder clianges. In 

my . emacs I have 

(global -set -key "\e[19~" ' save-buf f er) 

BO that "[doit]" in emacs saves my buffer. (ESC [19- is what emacs 
generates when I type the F8 key.) Similarly, in my .rk.keys file I 
have 

accept_to__end_of_line "*[[19-" # F8 
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so that " [doit] " at a shell running the Reactive Keyboard will accept 
the prediction and execute the command line. 

That should give you the flavor, choosing one function key for a given 
voice macro and then customizing multiple programs to react to that 
key in a similar manner. 

As for the KP_F* keys, ray .twmrc has something like: 

"KP_F1" = : all : f.warpto "Emacs" "KP_F2" = : all : f.warpto "Xmh" 
"KP_F3" = : all : f.warpto "XTerm" 


From: dana@sybase.com (Dana Bergen) 

Here is a way to get those coordinates for pointer jumps. I use olwm 
and I have the following in ray .Xdefaults: 

olwm . ShowMove Geometry : True 

This means that when you grab a window or icon and move it, the 
coordinates are displayed. If I want to know the coordinates of a 
location I drag an icon over to it. If you want the location relative 
to a window, just subtract from the comer coordinates (or move the 
window to 0,0 before you start) . 
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Contributed Voice Macro Sets 

Several people have contributed their voice macro sets for general 
consumption. Here are my (Simon Crosby) DragonDictate macros, emacs 
lisp code for programming, and my vtwm key bindings . Please note that 
I'm no great lisp hacker and if you have any improvements, I'd be most 
grateful . 

Dana Bergen's voice macros are here. Dana had this to say about her 
macros: "Here are my global macros, followed by my Frame macros, with 
some explanatory remarks interspersed. I agree with Jack that you'll 
want to mostly create your own macros on the fly to suit the way you 
work. However, these will give you some ideas." 

From: dana@sybase.com (Dana Bergen) Siibject: vi tip 


I experimented with using a special state for vi command mode, but 
decided that for the way I work it wasn't worth the trouble. The 
types of errors it prevents don't happen to me that often. However, I 
fotuid it useful to make the following changes to the [escape key] 
macro : 

-- Change the punctuation to "left right" instead of "invisible" -- 
Add the "lowercase-word" Dcom as part of [escape key]/ i.e., in the 
Edit window it should look like this: 

{Esc} {Dcom} lowercase- word{Dcom} 

This avoids the situation where the last thing you typed in input mode 
was a question mark or period, and your next command gets messed up by 
the spacing and capitalization. 

Here are Jack's macros (jack@eit . com) . Jack had this to say about his 
macros: "On the subject of creating macros and deciding which to 
create, I'd recommend simply creating what you need as you need 
it. The set I posted were the third or fourth set I'd developed and I 
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believe that each new set was smaller than the one before it. While 
this means that you can't sit dovm and enter everything you need in 
one session, it will create only what you do need; after the first set 
you can save them to ASCII and load them into a new version of Dragon 
or whatever. I found that looking at the first ASCII dump that there 
were many, many macros that I had completely forgotten about, mainly 
because I never used them more than a couple of times at 
maximum. Another point is that it takes some time to develop your 
"style" which will also affect what macros you create. There are also 
linguistic choices to make on the basis of phonetics; you want phrases 
that are as discernible as possible. For example, I had the hardest 
time using the phrase "enter key" because it sounded like so many 
other things. I found that using the phrase "carriage return" was much 
more easily discernible from other parts of ray vocabulary. " Here are 
some macro files for lisp, latex, and emacs, contributed by Wati 
{taylorw@marie.rait.edu (Washington Taylor)}. Here are his emacs lisp 
macros for cursor control. Says Wati: "Files are separated by 
"================". There are some macros in the latex and emacs files 

which are specific to my own purposes -- I commented some of these out 
but left them there as examples. Hope this is useful. (I don't program 
much in lisp, so that file is fairly short -- the latex file, however, 
is probably almost everything you need unless you are an extremely 
serious user) " Return To Contents List 


Useful DCOMS / Macros 


From: taylorw@marie.mit.edu Subject: "enter key" 

> From Jack jack@eit.com > > .... For example, I had the hardest time 
using the phrase "enter > key" because it soxmded like so many other 
things. I found that using > the phrase "carriage return" was much 
more easily discernible from other > parts of my vocabulary. > 

Since I want to hit the enter key frequently, I use the 
single- syllable word [ret] for the enter key. I don't have cuiy 
problem with dragon confusing this with "bet", "net", "debt", "get" or 
anything else. And it certainly speeds things up. In general, I use 
shorter utterances for frec[uently used words, as in natural language 
or Huffman coding. 

From: Simon Crosby 

> From: Rob Hutten Subject: The dangers of voice recognition oh man. 

> This just happened: Phone: Ring, ring. Me: [to DragonDictate] Go to 

> sleep. Phone: Ring, ring. Me: [answering phone] Voice console? 

> aargh. 

Easy to overcome this. Train DD to recognise the phone and turn 
itself off automatically. I have a macro which produces no output, 
which is [phone ringing] . 1. Get someone to call your office when DD 
is "live". 2. DD will spit out some garbage after the first ring. 
3 . Pick up phone after first ring to stop it 4 . Correct DD by saying 
"begin spell mode" and then enter the new macro such as my one above, 
with no key strokes. 

5. Repeat \mtil DD is trained. 

6. The macro should be as follows: 

add-word /g /t "[phone ringing]" " {Dcom} console {Dcom}g" 

Voila I 

This will turn off the mike whenever the phone rings. 
From : Scott@ccgate . dragonsys . com 
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>I am hoping to be able to run programs which are incompatible with 
>DragonDictate without too much pain. I am hoping to do this by, in 
>an automated fashion, > > 1. unloading DragonDictate > 2, running the 
incompatible application > 3 . loading DragonDictate 


>can anyone help me? 

There is a program in the DICTATES directory called UNDO. EXE. Run 
this to unload DragonDicate . If you have changed your voice files, 
you will be prompted to save them. 

If you do not want to be prompted to save your voice files, start up 
DragonDictate with the /v command line switch, e.g., 

dd /v [other options] 

This will allow DragonDictate to unload without stopping for anything. 
Be careful with this switch though, you may lose new training, words 
and macros if you haven't saved your voice files. 


Return To Contents List 


Useful Shell Scripts 


Prom: Simon Crosby Simon.Crosby@cl.cam.ac,uk 

Here's a useful bash macro which saves the "/" in dictating file names 
and paths on unix: 

In other words 

cd foo/bar/baz "cd foo slash bar slash baz" becomes 
cd foo bar baz 
cd 0 { 

builtin cd $* 
shift 

for i in $* 
do 

builtin cd $i 

done # the following is useful if you frequently Is when you 
get there. . 

is } 


From: daf t@debussy . crd.ge . com (Chris Daft) Mike Burrows was kind 
enough to send this solution for the C- shell. 

There's probeJsly a more efficient way, but this csh alias for 
cd does something similar to Simon's shell function: 

alias cd chdir \^echo \!\* \| sed \'s, ,/,g\'\*' \; pwd 

This makes: 
cd foo bar 
turn into 

chdir "echo foo bar | sed 's, ,/,g''* ; pwd 
which then turns into 
chdir foo /bar ; pwd 
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Mike Burrows 


Return To Contents List 


PC Telnet Software 

Most people seem to use PC-NFS 5.0, which includes a telnet program 

suitable for use with DragonDictate . Nobody has reported problems 

using this software, which also lets you mount nfs files over the net 

{so for instance your voice files could live on Unix or 

whatever) . People have experienced problems with some other telnet 

software: 


From: etonumo@hisoy.etn.eriGsson.se {Ulltveit-Moe Nils) To: 
a2x-uaera@x.org Subject: query: telnet trouble. 

I am a new DragonDictate user, and have problems with getting Telnet 
to work properly with PCTCP. 

The tn program seems to read the keyboard hardware itself/ so it does 
not work with DragonDictate. There is also another Telnet program 
supplied (tnglass) which works with DragonDictate, but does not do the 
right terminal emulation/ so for instance the arrow keys does not 
work. 

From: sproul@sybase . com (Nelson Sproul) 

PC/TCP works with DragonDictate if the latter is executed with the /k9 
switch - 


From: RDruker@RohmHaas.com {Mr. Ross Druker) 

We have successfully compiled a2x for AIX 3.2.4 (has XTEST Extension 
1), and ♦can* do the following operations via DragonDictate: 

o change mouse position 

o change window focus 

So we know things are close to working. However, we can't "type", 
that is, when we speak or type keyboard input from the PC, it does 
*not* get echoed on the UNIX machine. 

Using -e (for debug). Is yields "Is "^M" on the PC. 

Can anyone help? Is there a command to turn on keyboard input, or is 
there another problem? 

BTW, we are using FTP Software's TN program on the PC (version 2.3) . 
From: dp®world . std . com (Jeff DelPapa) 

The problem is in TN. You will discove when you exit it, all the 
stuff you dictated will appear at your dos prompt. TN looks directly 
to the keyboard hardware, and ignores the DOS keyboard buffer. FTP 
software was completely unwilling to do anything when I reported it a 
year ago, but may have moderated. (the telnet that comes with DV/X 
doesn't have the problem, so I didn't push things) . 

From: rbd@sst.ll.mit.edu (Robert B Dunn) 

> I am running DragonDictate on a PC connected on an ethernet and 

> trying to get the PC output to my Sparc 2 workstation. I can 

> accomplish this using the Desqview X software, but 
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I had the same problem with my version of telnet. I think some 
versions of telnet lock out DD. I use Kermit (IBM- PC Kermit-MS: 
2.32/A 21 Jan 1989) to connect to the sun through the serial port. 
This works fine for me, and the DD popup windows come up on my PC 
screen which I have next to my sun workstation monitor (which I find 
satisfactory) . I suggest you get kermit or find out what version of 
telnet other a2x users have. 

When you run ac2 through your telnet you should be able to type on the 
PC keyboard and have the output come up on the sun. Typing {c-t}{c-e} 
on the PC in the telnet window should gracefully exit a2x. 
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The a2x Olympics 

Finally, a bit of humour. Note that some of the contributed macros 
above will solve some of these problems, but they still remain the de 
facto test of skill for voice work : - ) 


From: dana® Sybase . com (Dana Bergen) 

Announcing the first-ever competitive event designed to show off the 
special talents developed by DragonDictate users! 


Speed Category: The Multiple -Headset Shuffle 

This event is for DragonDictate users who also use a telephone headset 
to reduce neck strain. The telephone rings, and the user must do the 
following ; 

1) say "voice console", "go to sleep" 

2) remove microphone headset 

3) remove music earphones 

4) put on telephone headset 

5) say "hello" 

All five actions must be completed before the caller hangs up or voice 
mail picks up the calll 


Physical Dexterity Category: The Coffee Ballet 

In this event, the user must drink a cup of hot coffee while using 
DragonDictate. Points are deducted for: 

-- bumping or moving the position of the microphone 

- - burning one ' s mouth 

-- dribbling coffee down one's face 

-- spilling coffee on one's lap 

spilling coffee into the microphone 


Vocal Dexterity Category: Sending Private Email 
The user enacts the following scenario: 

You have just had a fascinating new sexual experience. You 

want 

to tell your friend, who lives in another country, all about 

it 

without paying for a lengthy long distance phone call. 

Describe 


Exhibit C8 


Page 46 of 598 


your experience in detail using DragonDictate, speaking loudly 
enough for DragonDictate to function but quietly enough that 
your co-worker in the next cube can't hear you. 

Dramatic Talent Category: The Pantomime 

A new employee drops by to talk to the DragonDictate user. He doesn't 
know about DragonDictate and believes the user is on the phone. The 
user must convey the concept "no, you're not interrupting rae, just a 
second" before the visitor turns and walks away, without causing any 
erroneous keystrokes to be typed. 


:-> 

Return To Contents List 
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The DragonDictate FAQ 

Currently maintained by Simon Crosby entirely by voice, using 
DragonDictate and a2x. 

A related FAQ, the a2x FAQ contains information about using 
DragonDictate with the a2x program, which allows you to connect a PC 
running DragonDictate to a workstation which uses the x windows 
environment, and control the workstation's graphical display and 

applications . 

These FAQs are direct copies {shortened where possible) of postings to 
the a2x mailing list, the SOREHAND mailing list, and the C+HEALTH 
mailing list. Send contributions/corrections/updates/ideas to me. 
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DragonDictate support on the net 

DragonDictate support is now available over the internet at 
support@dragonsys . com 
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How Easy is it to use DragonDictate ? 


From: Dana Bergen 
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>I had a demo of DragonDictate today. I have a couple of questions, 
>though. How easy is it to install and learn? The reseller wants what 
I >consider a hefty chunk of money ($250 to install + ($250 x 2 for 
two >4-hour training sessions) « $750 total) to install and train me 
on it. 

This is insane. You don't need anyone to train you on it. It comes 
with a tutorial and it's not difficult to use. The "more advanced" 
features like creating macros and using dooms are reasonably well 
explained in the manual. 

>I'm pretty comfortable installing things in my PC (I put in a sound 
>card and a tape backup unit myself) , but he was talking about 
>configuring interrupts, which I know nothing about. 

I didn't install the card myself because my hands aren't up to using a 
screwdriver but I don't think it's any big deal. I think that 
configuring the interrupt is just a matter of setting a switch on the 
board. If you're on a network there are some additional issues, if 
you're concerned about this you might try negotiating a much lower 
price for him to just do the install. Better yet, try it yourself and 
only pay for help if you get stuck. 

> following a tutorial and reading a manual. On the other hauid, I want 
>DD to work, and I want to feel comfortable using it, otherwise it's a 
>waste of $$$. 

With respect to the installation, it will either work or not work. 
It < s not going to work badly or differently because you installed it 
wrong . 

I think your reseller is trying to recoup the money he's not making 
since they cut the price. 
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DragonDictate l^grades v2 to v3 


From: taylorw®marie. mit.edu (Washington Taylor) 
Joe Steffen writes: 

I moved my DragonDictate 2 . 0 voice files to a PC with DragonDictate 
3 , 0 and converted them with the modvoc program that ' s used for 
upgrading to 3.0, then used DragonDictate in my normal work for a few 
hours . Modvoc copies all your words and macros and preserves your 
voice training, but it still has a few problems: 

1 . Word pimctuation attributes are not preserved, both for words you 
added and special character punctuation you changed, e.g. I changed 

to cling left and right so it's easy to use in file name and 
regular expressions. 

Do you keep most of your macros in files? if you do, it is easier to 
keep track of and edit them. Furthermore, when you upgrade you can 
simply edit those files to the new format and fix punctuation 
automatically. I haven't upgraded to 3 yet, but even upgrading from 1 
to 2 it only took a few minutes to write emacs macros to update my 
macro files. 

2. Trailing spaces on words are removed. This is a problem for me 
because I define most computer command names to have a trailing space 
and cling right so I can say "*" after them. 
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Again, this problem would be fixed by using macro files. if the 
internal representation changed, you could use a command like add- word 
ft /g "foo" "foo " r (version 2 syntax) 

I went through the first part of my vocabulary online and counted over 
170 words such as file suffixes like ".bat" and parts of file paths 
such as ".,/". I estimate I have over 200 such words and special 
characters with changed punctuation attributes, so unless modvoc is 
fixed I'm not spending the money to upgrade. Note that there is no 
way to dump words in DragonDictate 2.0 so all of the above has to be 
corrected by voice. 

Again, using macro files would eliminate this problem. 

I had the same error rate (3%) as with DragonDictate 2.0. Has anyone 
seen an improvement in recognition accuracy after upgrading from 2.0 
to 3,0? 

I had 98% recognition with version 1. I have 98% recognition with 2. 
I expect to have the same with 3 and the windows version unless they 
have radically improved something. The only difference was the time 
to reach the plateau, which was months for l and days for 2. 

> From: "Susan Mailer ()" 

> Has anyone out there upgraded from dragon 2.0 or 2.01 to Dragon 3,0? 

> How do you like it? Do you notice a significant difference? PLEASE 

> REPLY. Susan Mailer maller@madonna.coedu.usf.edu 

Yes, I'm on 3.0 Classic - still with a 30K vocabulary. I found that 
recognition has improved, particularly for words like "last" "cast" 
"castle" in which the British flat "a" caused a problem. I no longer 
have to try to sound like an American on these :-) 

Also slightly faster, I think, but that is subjective and I have no 
proof. So, no significant difference but I'm happy with the upgrade. 
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What Sound Cards Can I Use ? 

DragonDictate for DOS uses the IBM M-Audio Acquisition and Playback 
Adapter, M-ACPA, which is an ISA-based card. This card is used for 
digitizing the audio and for doing FFTs on the digitized samples to 
assist recognition and reduced the CPU load. Read on for further 
information about these cards and the cards used by the windows 
version. . . 


From: Scott@ccgate.dragonsys.com 

>Also, (forgive ray ignorance being a non-PC oriented person) could 
>someone tell me whether there is a PCMCIA, or PCI M-ACPA card 
>available, or a similar card which DD can use ? 

There is not a PCMCIA version of the M-ACPA card. At this time, 
DragonDictate for DOS can only use this card. As you may have 
gathered from reading the mailing lists, DragonDictate for Windows can 
operate on a Windows sound card like a SoundBlaster 16, the 
MediaVision PAS16 and the Microsoft Windows Sound System to name a 
few. 


Return To Contents List 
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DragonDictate for windows or DOS ? 


From : Jack 

» but in my opinion, the technology just isn't there to »give you 
both adequate performance and to also have the DragonDictate menu pop 
>>up on the workstation screen. 

>I'm puzzled by this reroark. I have the DragonDictate menu on my 
workstation >screen, and the performance seems quite adequate to 
me. (The accuracy, on the >other hand... but that's a different topic.) 
Do you mean that >you experienced a noticeable delay between saying a 
word and seeing it >typed, or that you had to wait for menus to be 
drawn? This has not been >my experience. Or do you mean that you can 
speak more quickly if the >menu is not exported? 


What I mean is the following. I regularly use Dragon to run an X 
display. The way I'm using it is to have a PC monitor next to my 
workstation monitor. After using this for about 1 1/2 years or so, 
(the point being that I had become accustomed to a certain level of 
performance) I saw a demo of the Windows product. Point blank the 
performance was visibly worse than what I am used to, I surmised that 
the reason for this was that the Windows display takes processing 
power to update, which is true. The Dragon Systems rep basically 
agreed with me, though he was surprised that I noticed. The main 
thing is, anything you ask the PC to do other than voice recognition 
is taking cycles away from the recognition engine and giving thera to 
some other task like updating the VU meter, for example, which is 
constantly responding to the volume of your voice. 

Someone else said they didn't think that the Windows version was 
slower, and then went on to explain that they were already using an 
exported menu that appeared on their actual workstation display and 
explained that since the exported menu was already taking a certain 
amount of processing power, that the additional amount required to 
update and maintain the Windows display was insignificant compared to 
what they were already putting up with. 

My problem is that I could easily see that the Windows version was 
slower than what I was using; since what I'm using needs to get 
faster, not slower, this is not a solution I am willing to consider. 
Also, since I rarely have to look at the PC screen anyway as I just 
watch what happens in my X display, the benefit of running on a single 
machine or of having an exported menu pop up on my workstation (and 
cause the problems mentioned on this list with blotches due to bugs in 
deskview/X) is of little or no use to me. What I want is raw 
performance, period. Anything that will adversely affect that, and I 
could easily tell from the demo that the Windows display would, is 
just not going to make it with roe. Added to that, the Dragon rep 
basically admitted that it *was* slightly slower, so I basically 
bailed on the Windows product. This is not to say that I'm not into 
DragonDictate; I am, it saved my career. I just won't do anything 
that will slow my scenario down. 


From: stef f en®iexist .att . com (Joe Steffen) 

I installed DragonDictate for Windows last week. The first problem is 
you have to cancel the new user dialog and follow the README 
instructions to change the voice board default to the M-ACPA board. 

The second and worst problem is you can only transfer some macros from 
DragonDictate for DOS; you lose everything else: voice model training 
and all added words (I have a significant number of acronyms and UNIX 
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command names and options) . After two calls to technical support it 
wasn't clear which macros can be imported into DragonDictate for 
Windows; the format of special keys like control keys may have 
changed, so you will need to write a conversion script. You can't 
import macros with dcom's because they are replaced by a scripting 
language . 

The third problem was the tutorial quit after an internal error 4 
times. After doing the quick training, the tutorial finally worked. 
DragonDictate for windows operates differently so retraining yourself 
will be necessary, e.g. you say Voice Menu instead of Voice Console. 
I'm sure you can define a compatibility macro, but the macro language 
documentation is on-line and not in the printed manual, which I 
consider to be a problem since it is easier for me to read a paper 
manual then control a help program by voice. 

So now I'm considering upgrading to DragonDictate 3.0 since I will 
continue to use DragonDictate for DOS for most of my work, which is on 
UNIX and a Macintosh. 

From: Sebastian Seung 

I just got my DOS to Windows upgrade from Dragon Systems. The user 
interface is well done, but the documentation is not so good. My 
greatest disappointment is that it doesn't work with PC-XWARE. I 
called Dragon's technical support/ but they were ignorant of the 
problem. Does anyone know the reason for the incompatibility? Or has 
anyone else found a compatible X terminal program for the PC? 
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DragonDictate vs Kurzweil Voice 


From: George Hu Subject: Kurzweil Voice 

I am fortunate to have both Dragon Dictate and Kurzweil Voice for 
Windows, and would like to provide some comparison. It seems that 
Dragon really dominates this mailing list, possibly due to having 
multiple dealers on the alias. While Dragon is a very good product 
which has developed many features which are very useful, Kurzweil has 
some advantages which everyone should examine. 

In my opinion, Kurzweil has a much better recognition engine. Out of 
the box, Kurzweil beats a trained Dragon, and over time it still beats 
Dragon. When I use Dragon, I find it mistakes words a lot, and often 
doesn't have the right word in a choice list of 10 words. Kurzweil, 
however, very rarely makes an error, when it does make an error it is 
usually on a word which does sound ambiguous, and the choice list of 5 
words has the correct word in the list much more often. Dictating 
this whole document, I probably made less than a dozen errors! 
Kurzweil is also faster than Dragon on the exact same system. This 
may be do to Kurzweil still using a specific hardware board whereas 
Dragon is running off of a Windows sound system card. These two 
advantages mean that I want to use Kurzweil, but do not look forward 
to using dragon. 

Dragon has a much better set of macros and customization. If you 
intend to do programming, or other non-dictation activities. Dragon 
may be the only system which can work for you. Dragon allows you to 
control the mouse and buttons by voice whereas Kurzweil does not. 
Dragon can read text off of buttons and allow you to speak them 
whereas Kurzweil only has a few predefined buttons you can say. 
Dragon allows you to create hierarchical macros and has sophisticated 
things you can do inside macros such as control spacing and 
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capitalization, Kurzweil does not. 

Kurzweil is a simpler product to use. There is no command vs. dictate 
mode. There are no flags for spacing and capitalization you have to 
set before saying a word. Kurzweil allows you to correct spacing and 
capitalization afterwards. For correcting errors in previous words, 
you don't need to enter a special oops mode; you just say " backup 2" 
or whatever. Kurzweil has a manual of about 70 pages; Dragon comes 
with three manuals totaling over 315 pages. Kurzweil also comes with 
many application macros which I have found easier to use than for 
Dragon, although that probably varies a lot depending upon which 
programs you run. 

Eventually, Kurzweil will probably have all the features of Dragon. 
It will be difficult, however, for Dragon to change their whole 
engine. Eventually, both these products will be put out to pasture by 
continuous recognition systems. Today, I think the choice is between 
recognition accuracy, and features. If you want a dictation system 
for actual English dictation and moderate application control, then 
Kurzweil deserves serious attention. If you intend to do programming, 
or other things which must be highly customized, then you probably 
need the features of Dragon. 

Lastly, Kurzweil is retailing at about 1000, which is a bit more than 
Dragon. Both systems can run on similar platforms, but I think 
Kurzweil is faster. Sometimes, Kurzweil can require more virtual 
memory than Dragon, but both are basically memory hogs. I run both on 
a 66 megahertz 486 with 16 megabytes. 

Prom: Gary R Noonan Subject: Re: Kurzweil Voice 

My approximately year long experience with the DOS version and 
approximately 2 month experience with the Windows version of Kurzweil 
support the comparison provided below. The Dragon dealer was unable 
to make his system perform with anywhere near the accuracy of Kurzweil 
when I examined DOS systems. The Windows version of Kurzweil is 
indeed very good at voice recognition- -even without training. 

I recently found a method to have Kurzweil produce mouse clicks on 
selected windows. Simply start the Windows Recorder macro system 
(found in accessories window) and assign unique keystroke to the macro 
(such a Shift + Alt + Ctrl + a) and make the desired mouse clicks. 
Then create a macro in Kurzweil that issues the hotkey for the Windows 
Recorder macro. This procedure allows you to have the Kurzweil system 
perform mouse clicks by voice. You can of course also create macros 
within individual programs and have Kurzweil call them. I have 
created numerous voice activated macros in WordPerfect for Windows and 
call them from Kurzweil, often performing complex tasks with a single 
voice command. 
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DragonDictate vs IN3 


From; Dana Bergen 

=«> I've been looking into IN3 and am considering buying it. However, 
there » is no demo version, and no money-back guarantee. So as far as 
the » company is concerned, I have to put down $700 sight unseen with 
no >> guarantees. Is there anyone in the Boston area (I'm in Waltham) 
who is >> using the product and would be willing to give me a short 
demo so I can » get a better feel for this product before pltinking 
down $700? 

IN3 costs $700? Why spend $700 for a limited command set when you can 
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get a full-fledged dictation system (DragonDictate) for $1000? 

I have no financial interest in this recommendation. I use 
DragonDictate and a coworker used to use IN3 , and they are in two 
completely different leagues, I don't understand how IN3 can get away 
with charging that much given what DragonDictate costs now. 

From: Nelson Sproul 

» I just got DD for Windows to use it with Unix. I don't know how 
smart that was >> (I'm beginning to wonder if I should have gotten 
IN3) . . . 

you are better off with DragonDictate than inS . 

when my hands first went bad/ I wasn't aware of the DragonDictate/a2x 
option. Despite warnings from in3 ' s customer service that I would "go 
crazy" using in3 as a substitute for typing (as opposed to just using 
it to handle mouse functions) / I used in3 for one year, getting barely 
acceptable performance with a vocabulary of about 150 items. This 
vocabulary allowed me to spell words out, which was of course an 
excruciatingly slow method, though one I was still grateful for since 
it allowed me to continue work in this field. 


Now, using DragonDictate, I have superior performance AND a vocabulary 
of 30,000 items. I mentioned this to an in3 rep, and all he could say 
was that my Sun, a spare ipc, is not a very strong machine. I don't 
think this accounts for a difference in performance/utility of two 
orders of magnitude. I haven't seen in3 run on a PC, but I called 
Command Corp. (in3's manufacturer) today and they say in3 ' s 
performance is comparable on the two platfoirms. I also asked what was 
the largest vocabulary size they would expect, and 1 was told "at 
least a couple hundred." 

Needless to say, a vocabulary limited to hundreds of words is not 
acceptable for an English dictation system for adults . I have never 
flamed anyone/anything in my life, but it appears to me that, given 
the availability of DragonDictate and a2x, inS is a hoax. 


From: Nick Parker 


Nelson Sproul wrote: never flamed anyone /anything in my life, but it 

> appears to me that, given the availability of DragonDictate and a2x, 

> in3 is a hoax, 

I can see how using IN3 for text dictation would be very 
f 3:ust rating . I'd compare it to chopping down a tree with fingernail 
clippers. It's possible, but geeeeeeeeeeeez ! It's certainly unfair to 
complain afterward about the design of the fingernail clippers, , . 

I've never seen INCUBED represented as a "dictation system." It 
certainly isn't called that in the Command Corp marketing literature I 
received, nor in the IN3 product documentation I received when I 
bought the package. 

It's all a matter of selecting the right tool for the job. Almost all 
applications require a large amount of command selection -- that's the 
nature of graphical user interfaces, and feature laden software. When 
you count up cuts and pastes, font changes, saves, moves, etc, even 
writing a simple text document has a LOT of command and data 
selection. In the case of CAD, dtp (which is almost indistinguishable 
from word processors these days) , or other similar applications, the 
user- computer interface is comprised almost entirely of command and 
data selection. A good voice command system, like INS, can perform 
these functions via voice, and drastically reduce the amount of button 
pushing you do in a day. A continuous dictation system might do the 
same, but at a much higher cost. Both dictation systems and command 
systems have their place -- it's a matter of selecting the right tool 
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for the job. Command systems will benefit everyone, and dictation 
systems will give an additional benefit to those who need it. 


I don't think IN3 is a "hoax" --at all. It is very robust and 
effective software. The last literature I saw lists the prices at $179 
for the basic version, and $395 for the Pro version, which includes a 
very nice Audio Technica Pro 8 headset microphone. Not bad. And no, I 
don't have any affiliation with Command Corp. I'm just a satisfied 
customer: IN3 did what they said it would do. 

From: Ann Marie Lawler 

> IN3 costs $700? Why spend $700 for a limited command set when you 

> can get a full-fledged dictation system (DragonDictate) for $1000? 

Well, that's IN3 plus a top- of- the- line noise-canceling microphone. 

If you're on MS-Windows, IN3 doesn't cost anywhere near $700 and if 
you're on a SPT^RC station you've got to add the cost of the PC, the 
sound card, and possibly the communication connection to DD. Maybe 
you've got a free com port, maybe you don't, it's just that much more 
hardware. That plus find a place for that second box, and keyboard, 
and screen. . . Sigh. . . 

Then you also have to get a2x running. According to the documentation 
with the copy of a2x that I have (distributed with the X11R6 sources) 
it won't work with the Sun OpenLook version 3 (current release) out of 
the box. You have to have X11R6 running or a patched version of X11R5 
with the XTEST extensions patched in. 

> I have no financial interest in this recommendation. I use 

> DragonDictate and a coworker used to use IN3 , and they are in two 

> completely different leagues. I don't understand how IN3 can get 

> away with charging that much given what DragonDictate costs now. 

Well, IN3 and DD are in different leagues. They are different 
products designed to do different jobs. One is a command system, one 
is a dictation system. I type just great. In fact, some of my 
co-workers think I type faster than I talk. My typing was not where 
my problems were starting. If you can't type at all I guess you need 
a dictation system. If you can still type and want to prevent further 
damage, maybe a voice command system is a better choice. One product 
is not necessarily better than the other, they're just designed for 
different jobs. 

My problems started with that dam rat (ahhh. . . I mean mouse) . When 
you squeeze both sides and hold down a button while dragging something 
around on a desktop, the stress goes right to the wrist. Added to that 
were multi key cords . ~F and ~B in vi as well as some of those lovely 
Alt -Function keys for WordPerfect had me stretched accross the 
keyboard like I was palming a basketball. Ouch! 

If your hands are already so injured that even normal typing is no 
longer possible, I'm sorry to hear that and I guess you don't have 
much choice. I prefer to not get that bad. I replaced all the fancy 
command operations with voice macros. Now my typing doesn't bother me 
at all. I can even type faster than I used to because I've reduced 
some of the distraction when doing commands. I caught ray problem 
early enough so I guess I'm one of the lucky ones. I'd rather do the 
commands and functions by voice and still type rather than be forced 
to do all of my typing by voice. 


Prom: Simon Crosby 

> From: Ann Marie Lawler 
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> Actually, I would not be suprised at all, having worked with 

> a2x as well as other products which require "clever window manager 

> key bindings". That's actually why I made the statement. There was 

> just too much you cannot do with key bindings. After a while you 

> also get tired of cluttering up configurations with obscure kludged 

> together key bindings. And changing key bindings "on the fly" is 

> not a lot of laughs. Most people don't what to be forced to be 

> "clever" just to use something for a purpose to which it was not 

> designed. Most people would rather use something that is easy to 

> use and designed for the purpose to which they are applying it. 

On the other hand, a2x is not a product, nor does it claim to be. It 
solves a problem, and does it exceedingly well. There are lots of 
people out there (like me) who cannot type. My career would be in the 
dustbin (US = garbage can) by now if I were not in a position to: 
1. Write technical documents 2. Write programs in lisp, C, assembler 
and various other gunk 3. Manage a computer network All by voice, on a 
unix workstation. DD is the ONLY product which I have seen which will 
currently allow all of these, in spite of its flaws. 

> Actually, according to the sources, a2x has some pretty fancy 

> features > built into it that many people don ' t even know 

> about. Maybe because they > are so archane to try and figure 

> out. "That's a control T ?what? for a > window class?" "But 

> that command is suppose to do different things in > those 

> different windows." And once you're set up, changing them on 

> the fly > is difficult at best. And the recognizer still 

> doesn't know what's happening > on the screen or if something 

> succeeded or not. Then there's that extra > box and screen 

> and keyboard and sound card. . . 

Yes, a2x needs a language front end, and DD needs to be "application 
context aware" . It also needs a *much* better undo mechanism than its 
current "throw out backspaces" idea. Ideally voice recognition/ input 
should be an integral part of each application to guide recognition 
and so on ... One of these days perhaps. . . But remember, a2x is free. 
It also works well enough in conjunction with DD to be very useful. 

> The thing about IN3 is that it is easy to setup and use and to 

> change > commands while remaining a powerful command 

> processor. It just does a lot > of things which cannot be 

> done through key bindings. Things like warping > to a 

> location within a window of a particular title. Or combining 

> functions > where one function depends on the success or 

> failure of a previous >f unction. 

Great. I have no problem with IN3 -- If it solves a problem or has a 

niche, then I'm 100% behind it. Remember though, that not everyone 

has a sparcstation. What do I run on my alpha box ? 

> It might be possible to combine key bindings with piles of shell > 

> scripts and come close to some of the advanced features of 

> INS, but not all. > There are things which you still cannot 

> do, even with key bindings and shell > scripts. But do you 

> really want to spend all of that time writing clever > shell 

> scripts to go with all those clever key bindings? Just to do 

> a few > of those things which key bindings cannot do? Just to 

> use a product for > something it was not designed for? 

No I don't want to spend hours doing this. I spent about 1.5 weeks, 
once, and now I can do almost everything I need. Admittedly not very 
sophisticated, but it works. If you can add value in a product and 
people will buy it, then great. I wish you the very best of luck. 
And yes, I'm sure you have fantastic functions which I'd love to have, 

> If you need a dictation system, get a dictation system. If you 

> don't > need a dictation why get one to do something other 

> than dictation? Different > products for different jobs. 
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My DD world is more than a dictation system, it is my whole 
human- computer interface. This may well be true of IN3 , now or 
someday, and I agree IN3 can help save people's hands by reducing hand 
strain. 


Return To Contents List 


What helps / hinders recognition ? 


From: stef f en@iexist .att , com 

>From att Ix. org 1 pub-mailer Mon Sep 19 17:19:33 1994 From: 
dorab@twinsun.com (Dorab Patel) To: a2x-users@x.org Subject: what 
helps / hinders recognition 

The recent discussion aibout hoarseness and recognition efficiency 
during a cold reminded me of a question I've been meaning to ask... 

In your experience, what do you find that helps recognition accuracy? 
What seems to hinder recognition accuracy? 

I keep my office door nearly all the way closed, otherwise the higher 
background noise increases errors. I'm vigilant about correcting 
misrecognitions and if I ever leave the mike on during a conversation 
so there are more false recognitions than I can correct, then I revert 
to the last saved voice models; otherwise your voice models get messed 
up and your error rate goes up until they are retrained. I keep track 
of common misrecognitions of voice macros and change one of them even 
if I've used one of them for a long time so my mental retraining is 
difficult. For example, [c[uit UNIX] often sounded like [quit emacs] 
so I changed the former macro. In 11 months my error rate dropped 
gradually from 8% to less than 3%. 
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How About DragonDictate for the Mac? 


Articulate Systems' licence DragonDictate for the Mac, and the product 
is called PowerSecretary . Anyone with a review please let me have it. 
Articulate Systems: +1 617 93 5-5656 


From: "Gary L. Karp" Date: Tue, 1 Nov 1994 06:54:27 GMT 

A brief update on my recent post on the PowerSecretary dictation 
system for the Mac from Articulate Systems. 

I had understood it was necessary to dictate into a separate window 
and then copy into the application. This has turned out to be only 
partially true. One may dictate into any application, but cannot 
correct by voice unless they work in the separate window. 

The good news is, an update will release in November which corrects 
that. It will be possible to dictate and correct in any application 
window . 

I feel confident based on discussion with Articulate that they are 
committed to eventually meeting the full set of Dragon features on the 
Mac. I will be getting the system, and will report as I get it 
running . 
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It will remain necessary to have a minimum 040 system. I am getting a 
PowerPC. It will also run on PowerBook 540s without added boards or 
peripherals - except the microphone, of course. 

A company in the Bay Area, Scott Tech, has a solution whereby Dragon 
is pumped through a small PC and out to a Mac in ADB format. This 
remains the answer for pre- 04 0 Macs. 
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DragonDictate and Notebook Computers 


From: Scott Jangro 
>From: Bob Wentworth 

>I just talked to Dragon technical support about using Dragon on a 
>notebook. >They say that most notebook sound systems don't do a good 
job of >emulating industry standard sound boards, and that Dragon does 
not >work well on these. However they do know of one notebook that is 
>100% compatible with the Microsoft Windows Sound System, Dragon 
>works fine on that. FYI, Dragon is at (617) 965-5200. 


To save you a toll call, here is the Windows Sound System compatible 
sound card that I think somebody here told probably told Bob about: 

WAV Jammer PCMCIA sound card New Media Corporation Irvine, CA 

800-CARDS-4-U 

This is not an entire notebook solution but a PCMCIA card that will 
plug into a notebook with a PCMCIA slot. We have tested the card here 
at Dragon and it does work very well with DragonDictate for Windows. 
It is a Windows Sound System compatible card and like the real Windows 
Sound System, it requires the use of a condenser type microphone (as 
opposed to a dynamic microphone which is what we've traditionally 
shipped with DragonDictate) . We do provide either type microphone 
with the DragonDictate for Windows. 

It is true that some sound card emulations do not do a good job at 
mimicing the real thing, but I would not say that it is necessarily 
*most*. The truth is that we don't yet know if most of them will work 
or not. The point is that one shouldn't assume that a card is truly 
Windows Sound System compatible (or SoundBlaster 16 compatible) just 
because it says it is. For example, it may allow you to run Windows 
Sound System's software drivers but the electronic characteristics of 
the hardware may not be of the same quality as the real Windows Sound 
System. While this work well enough to do recording and playback in 
Windows or to play WAV files, this may not work well on a technology 
like speech recognition that relies heavily on good quality sound. 

As far as information on any other sound cards goes, we are in data 
collection mode right now. We do rely quite a bit on user feedback for 
this infomration in addition to our own testing so if you have any 
information on notebooks or sound cards that work well or not with 
DragonDictate for Windows, I'd like to hear from you. Thanks. 

From: Scott Jangro 

We're currently putting together lists of laptop computers that work 
well with DragonDictate for Windows 

The company that you called has no connection with Dragon. That 
company is unique because they have a laptop that can accomodate an 
ISA card. This is important for people who use the acpa DSP card for 
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DragonDictate (required for the DOS product) . Therefore^ we refer 
customers to them as the only vendor that we know of with this kind of 
laptop. PWIW, I apologize for the difficulty you had in contacting 
thera. 

Now that DDWin can run on a standard Windows sound card, we have many 
more options. We're currently running experiments on different 
systems to put our seal of approval on some laptops that provide the 
best quality performance. Speech recognition is a very specialized 
use of sound input and requires high quality speech samples for good 
performance. Many sound cards just do not provide the quality sound 
that we feel is important for our product to perform the way we know 
it can. So while most if not all 16 but sound cards would pass the 
"go- into- the -software- store- and- see- if -it- runs" test, only a subset 
of those would produce the cjuality sotind for good speech recognition. 
It takes hours and hours of testing per card or laptop to determine 
this level of quality and we will provide this information to you as 
soon as it is known to us. 

At this time I can tell you that users are running DDWin successfully 
on the following computers. We have purchased these machines and are 
in the process of certifying thera. We DO NOT guarantee them at this 
time but preliminary tests are promising. 

Toshiba 4800 DX4-75mHz Everex Stepnote DX4-75mHz Ergo lOOmHz IBM 
ThinkPad 755 WAVjammer {PCMCIA card) 
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How About DragonDictate for Windows NT? 


From: Simon Crosby 

A person in Cambridge suffering from early stages of RSI wants to know 
whether there is a DragonDictate in the pipeline for NT. Anybody 
know? 

Also, has anybody done the equivalent of a2x for NT? I mean, PC doing 
the recognition and an a2x-like thing on an NT box. Is this possible 
(thankfully I have no knowledge of windows or nt) 

From: Hans Heilman 

>> Also, has anybody done the equivalent of a2x for NT? 

There is a hardware solution called a TTAM that takes ascii output 
from one PC and converts it into the correct electrical interface to 
go into the keyboard port of a second PC. It also does mouse emulation 
going into the second PC's mouse port. I think this is the 
configuration ; 

+ + + + Ipc 

running Dragon under [ + > [mouse port] PC running windows | |DOS, 

text goes out | | | 1 |port [output port] --> [TTAM] [keyboard port] | 
+ + - - + + I I 

keyboard mouse 


A friend of mine has been using this setup for a while so he could use 

Dragon for Windows development, before the DDWIN release (he was 
willing to live with having to have 2 PC's) . As an experiment, he 
swapped the righthand PC to be one running NT ajid everything seemed to 
work fine. 
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The TTAM is around $400 --a company called something like 
Prentke-Romich sells it (along with other assistive technology) . If 
you send me mail, I'll get the real name and address. 

From: dana@sybase.com (Dana Bergen) 


You couldn't control the mouse by voice with this setup, could you? 
Because Dragon for DOS doesn't have that capability. 

From: dp@world.Btd.com (Jeff DelPapa) 

If you have a PS/2 mouse, the ttara will control it. (takes special key 
sequences, but they can be done as voice macro's) The one I had (it is 
currently on extended loan) also had a MAC ADB connector, and could 
spoof both keyboard and mouse on that machine . Mine was made by 
Words+ in northern CA (who make lots of adaptive products) but they 
have since stopped. The box was originally designed by the Trace 
Center at UWisc /Madison, and was licensed to several vendors. 

Having said all that, there may be a minimal hardware solution. Under 
DOS, and Windoze 3.1 there is a "handicapped access pack" (available 
free for the asking from IBM and Microsoft respectively) One of the 
many things it provides is "serial keys" a setup that lets the 
keyboard and mouse be driven by data on the serial line. (you send 
"sentences" to access characters outside of the normal printing ones) 

I don't know if NT has such a facility, but since it was developed 
after the access pak became available, they may have built it in from 
the start. If someone has the NT doc set and wants to take a quick 
look, it would be appreciated. (I will be looking into this myself 

shortly, a co-worker will be in this spot soon) 

All of these presume a two computer solution. In the case of NT, with 
suitable software, you can use the DV/X trick and get the menu's to 
share the main screen, (dragon/dos won't run in a less than full 
screen ms-windows dos box, the video emulation isn't good enough). 

In the case of the TTAM, it does not support ps/2 scan code 3 
keyboards (unfortunate, as that is the code set that many X terms that 
adopted PC keyboards use) , so check yours. The vanilla PC (big 5 pin 
plug) keyboards are fine. The program to convert key events to the 
sentences needed by either ttam or the access pack does not exist in 
the pioblic domain. The Word+ people used to include a copy if you 
bought a ttam, but they wouldn't sell it separately, and it may be 
essentially unavailable now. I don't know what the others do. 

From: dp@world.std.com (Jeff DelPapa) 

I am glad we have the windoze NT documentation in machine searchable 
format. NT does indeed have a handicap access pack available for it, 
the page that tells you how to get it is in the appendix of the SNA 
Server development kit installation guide (I kid you not) . Anyhow it 
is /sof tlib/mslf iles/wn0789 . exe on ftp.microsoft.com. 

I got a copy, but haven't tried it yet. (toby will do so on monday) . 
Since I have the disks, I suppose I should try installing dd/win on NT 
and see what happens. 

From: Hans Heilroan 

One place I know the T-TAM can be ordered is: 
Prentke Romich Company 1-800-262-1984 

Their catalog carries a number of assistive devices, and also sells 
the T-TAM, apparently to connect their assistive devices to a PC 
(although it can also be used to connect 2 PC's together). They have 
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a fact sheet on the T-TAM which can be included. 

They list several different T-TAM models on their price list, so be 
clear with them on the details. 

Apparently, the T-TAM does have special input escape sequences defined 
which can cause it to generate mouse button actions, although my 
friend found that behavior to be somewhat flaky in different PC 
configurations (as opposed to the straight ASCII character input which 
worked fine) . He was fairly frustrated with mouse emulation 
difficulties. 

He was running PROCOM+ on the Dragon PC to send Dragon- generated text 
out the COM port, but ran into a limitation. Apparently, PROCOM+ 
allows user-defined sequences to be found to different keys, but the 
limit is 10 characters, which wasn't long enough for al of the special 
T-TAM sequences. He worked around this by coding a small ad- hoc 
program which reads input and sends it to the COM port. 
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DD Windows and PC X Servers 


From: Scott Jangro 
>>>>>>>>>>>>>>> 

has anyone used PC XWare with dragon? so far it looks like it might 
have problems ... 

<<<<<<<<<<<:<<<< We have heard of problems between DragonDictate for 
Windows and PC-Xware and I have followed up with the publisher of 
PC-Xware. Unfortunately, they have confirmed that their PC-Xware will 
not be compatible with DragonDictate for Windows . Further explanation 
below for those interested. . . 

As you may know, DragonDictate inserts keystrokes into the active 
Windows application. DragonDictate uses the same Windows facility as 
the Windows Macro recorder does to play keystrokes into a Windows 
application. Any Windows application that follows the Windows 
application development guidelines will be able to get input from the 
Macro recorder and from DragonDictate for Windows. 

PC-Xware doesn't follow the Windows conventions for getting 
keystrokes. Instead, it goes down to the DOS level, below windows, to 
get the keys. Therefore, they miss the keystrokes that DragonDictate 
for Windows is sending. They also told me that they're aware that 
they do not work with the Windows macro recorder. 

I wish there was something that we could do to make DragonDictate for 
Windows work with this application as it looks like a great solution 
for X/Windows users. They didn't say if they were planning on 
changing their application to conform to these Windows standards or 
not. If anybody does come across a Windows X/Windows emulation, I'd 
be very interested to hear about it. 

From: Jeff Del Papa 

I used Hummingbird's exceed with DD/win. Worked fine. I will also 
give the DEC (excursion I think) a try (it is what the UK branch 
standardized on) , when I am in the mood for shuffling floppies again. 
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Do you get hoarse from using DragonDictate ? 


From: rbd@sst.ll.Tnit.edu (Robert B Dunn) 

I am looking for some advice on using DragonDictate . The problem I 
have (which I think is fairly common) is that I get hoarse fairly 
quickly. Unfortunately this happens so quickly that I have not been 
able to make much use of DragonDictate and a2x, although I have had 
them for a few months. I now frequently get hoarse during normal 
conversations and occasionally have to stop talking to people. I use 
the following strategies to reduce the stress of using DragonDictate: 

1) apeak softly, 

2) drink very frequently. 


The following summary of a discussion of hoarseness was made by 
Scott@ccgate.dragonsys.com (Scott Jangro) . 

++++++++Original E-mail 

Posting+++++++++++++++++++++++++++++++++++++++++++++ I have been 
reading peoples' summaries of their experience with voice input for 
performing programming and related tasks, since I have considered use 
of this technology myself for a worsening RSI problem. It all sounds 
quite encouraging. However, at this time I have a few 
questions/concerns perhaps someone can address: 

1) have the users of voice input at work found that their talking 
disturbs their officemates? Has anyone needed to arrange for having an 
office to themselves? it seems that when office space is limited this 
may pose a problem. 

2) has anyone experienced hoarseness or similar problems attributable 
to the increased talking? Is it possible we may be partially 
substituting one problem for another? 

3) speaking of hoarseness, how do Dragon and the other packages 
perform when the user has hoarseness due to voice strain or a cold? 
Does recognition suffer significantly? 

Any insight on these questions would be appreciated. Thanks! 

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 
1) have the users of voice input at work found that their talking 
disturbs their officemates? Has anyone needed to arrange for having an 
office to themselves? it seems that when office space is limited this 

may pose a problem. this can be a 

problem . 


2) has anyone experienced hoarseness or similar problems attributable 
to the increased talking? Is it possible we may be partially 
substituting one problem for another? 


No problems. . . 


3) speaking of hoarseness, how do Dragon and the other packages 
perform when the user has hoarseness due to voice strain or a cold? 
Does recognition suffer significantly? 


I've found that if I already have a sore throaty working by voice can 
aggravate it. However, I have not had recognition problems even when 
♦completely* stopped up (as in runny nose, congestion, etc.). 
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++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 
>their of f icemates? Has anyone needed to arrange for having an office 
to > themselves? It seems that when office space is limited this may 
pose a >problem. 

I work in a cubicle. Most of the people around me say that my talking 
is "white noise" that doesn't bother them. Apparently one person has 
complained, and as a result I may be getting a private office (which I 
wouldn't normally rate) when my group moves in a month for two. If 
this happens I'm certainly not going to complain :-) 

>2) has anyone experienced hoarseness or similar problems attributable 
>to the increased talking? Is it possible we may be partially 
substituting one >problem for another? 

I had really bad voice strain the first day or two, but I changed the 
way I was speaking and the problem when away. I had taken a singing 
class and been taught how to project without straining my voice. When 
I used that technique I stopped having voice strain. 

>3) speaking of hoarseness, how do Dragon and the other packages 
perform when >the user has hoarseness due to voice strain or a cold? 
Does recognition >suffer significantly? 

I have allergies and my level of congestion varies a lot. Mostly it's 
not a problem. Sometimes on a particularly bad day I notice the 
recognition being a bit worse, but it's not a real big difference. I 
have two frequently used macros, [sniffle] and [clear throat] , which 
don't type anything. They work really welli 

Here ' s the mail I sent in response to the original inquiry, since 
people other than that person seem to be interested: 

I'm a Senior Software Engineer at Sybase. I do new feature 
development on the SQL Server, which is our core product. I 
investigate problems, write specifications documents, write code, and 
fix bugs. My work is in C in a Unix environment. 

I use DragonDictate all day long. I can't type at all without pain, 
so I do everything with DragonDictate. I think that the effect on my 
programming productivity is minimal; i.e. I get pretty much the same 
amount of work done with DragonDictate as I used to get done typing. 
It's a little more of an impediment when writing a document; I create 
documents somewhat more slowly than before. However, I'm perfectly 
capable of doing what's needed for my job. I was a very fast typist; 
DragonDictate makes me more like a fairly slow typist. There are 
plenty of engineers here who are not super fast typists who do a good 
job. My company esqpects the same amount of work from me that they 
expect from other people, and this has not been a problem. 

There was a pretty significant amount of time required to get going 
with DragonDictate in a Unix programming environment . Getting the 
various pieces of software and hardware working together correctly 
took some doing; getting macros and such set up took some doing; 
getting used to using DragonDictate took some doing. I spent a fair 
amount of time after hours working on my environment for the first 
month or two. During that period of time, I was doing my job using 
DragonDictate but wasn't as productive as I am now with it. 

++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 


1) have the users of voice input at work found that their talking 
disturbs their off icemates? Has anyone needed to arrange for having an 
office to themselves? It seems that when office space is limited this 
may pose a problem. 
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> > > I have found that I can dictate pretty softly, and it seems to 
work better that way anyhow. outside noise doesn't seem to disturb 
DragonDictate much, though. Classical music is just fine, as are 
conversations in the hallway, but it doesn't seera to like Devo music! 
As for disturbing my neighbors, as long as I talk relatively softly, 
that doesn't seem to be a problem {no worse than having a neighbor who 
spends all day on the phone, which is normal for some environments) . 

I think privacy may be more of an issue: you need to realize that now 
people can hear you writing your email i (Already a problem with phone 
conversations) . 

2) has anyone experienced hoarseness or similar problems attributable 
to the increased talking? Is it possible we may be partially 
substituting one problem for another? 

> > > Yes, hoarseness is a problem. Much better when I talk softly, 
which is desirable anyway. I also drink a lot of water and tea. You 
should treat it like typing don't do it for hours without stopping 
once in a while for a break, when I first got the system, my head, 
neck, cind shoulders bothered rae more, until I realized that I was 
essentially shouting at the system (like teaching a class without a 
microphone and trying to project all the time) . This is less of a 
problem now that I've learned that it works just fine with soft 
speech . 

3) speaking of hoarseness, how do Dragon and the other packages 
perform when the user has hoarseness due to voice strain or a cold? 
Does recognition suffer significantly? 

> > > Yes, it does suffer. It's really fun to dictate while crying! 
: - { You need to be sure not to save your voice files after such a 
session so as not to screw it up. It does still work, though. 

Any insight on these questions would be appreciated. Thanks! 


hoarseness has not been a problem for me, even when I was pulling a 
lot of all-nighters last summer/fall. 

the following will help keep you going longer: 

1) sip water frequently, and don't wait for your throat to get dry 
before you get something. 

2) speak softly and steadily 

3) avoid drinks with caffeine or the harsher pops. (I don't know what 
the mechanism is, but avoiding caffeine was suggested by a friend who 
is a singer. I did find that my throat would feel dryer and more 
irritated if I had had a lot of pop and I had been working at the 
computer . ) 

There are many professions where people use their voice all day. 'Its 
good to get suggestions from them. We have an advantage, because our 
voices must only carry to the microphone. 

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 

1) have the users of voice input at work found that their talking 
disturbs their officemates? Has anyone needed to arrange for having an 
office to themselves? It seems that when office space is limited this 
may pose a problem. 

DragonDictate is sensitive to noise, particularly to drawers and 
binders closing, although you can train an empty macro to these sounds 
it does interrupt and slow you down. I think a private office is 
important; don't be afraid to mention the American Disabilities Act. 
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2) has anyone experienced hoarseness or similar problems attributable 
to the increased talking? Is it possible we may be partially 
substituting one problem for another? 

I sip water all day and have had problems with hoarseness only when I 
let my cup stay empty. Drinking water also forces me to take breaks 
to go to the restroom. 

3) speaking of hoarseness, how do Dragon and the other packages 
perform when the user has hoarseness due to voice strain or a cold? 
Does recognition suffer significantly? 

DragonDictate works surprisingly well when my voice sounds different 
from normal. 

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 


> 2) has anyone experienced hoarseness or similar problems 

> attributable to the increased talking? Is it possible we may be 

> partially substituting one problem for another? 

I am responding to this question because I have had a particularly bad 
experience in this area. 

I began using Dragon extensively at the beginning of this year. After 
a couple of months, I noticed my throat was getting sore each time I 
used it. Being a performer in amateur theatre, I found that I was 
having to quit using Dragon by Wednesdays so that my throat could 
recover for a weekend performance. {In a dozen years of singing and 
acting, I have never experienced voice problems from performing.) 

The problems persisted and worsened. I asked our medical department 
if a voice therapist could be brought in to see what I was doing 
wrong. Nine weeks of aggravating bureaucracy later, I saw an ENT 
(ear, nose, throat) doctor who told me I had modules on my vocal 
cords. I immediately stopped using the system. 

While the nodules have since faded away, I continue to have pain in my 
throat from speaking (regular speaking) . So now I can neither type 
nor talk confortably. 

There is one other person here that uses Dragon, and though he is able 
to use it, he, too, had some much less severe throat problems along 
the way. Even now, if his allergies act up, he has some difficulty. 

I am glad to hear that others have not had much problem with this, but 
be advised that it can occur. This possibility is also noted in the 
best book on RSI we have yet to find, on p. 168 (RSI A Computer User's 
Guide, by Pascarelli and Quilter) . 
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From: 
Sent: 
To: 

Subject: 


llsa 

Wednesday, November 02, 1994 1:17 PM 

'software-checkins-dist' 

gnu-tools/si m/terp cycles, h 


Update of /p/cvsroot /gnu- tools/ Sim/ terp 

In directory calliope : /N/auspex/root/s6/lisa/src/gnu-tools/sim/terp 

Modified Files: 
cycles. h 

Log Message; 

Added trace_register () function and TRACE_REGISTER macro. 
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From: 
Sent: 
To: 

Subject: 


lisa 

Wednesday. November 02, 1994 1:21 PM 
'software-checkins-dist' 
gnu-tools/sim/terp execute, h 


Update of /p/cvsroot/gnu-tools/sitn/terp 

in directory calliope: /N/auspex/root/s6/lisa/src/gnu-tools/sim/terp 

Modified Files: 
execute . h 
Log Message : 

- Added extern declarations of new variables last_regs and last_thread, which are used to 
track the most recent instruction that modified a register. 

- Added macro TRACE_COMMIT, which picks out the appropriate information for a 
TRACE_REGISTER of the destination register (s). 
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From: 
Sent: 
To: 

Subject: 


lisa 

Wednesday, November 02, 1994 1:24 PM 
'softwa re-check i n s-d i st' 
gnu-tools/sim/terp execute.c 


update of /p/cvsroot /gnu-tools/sim/terp 

In directory calliope: /N/auspex/root/s6/lisa/src/gnu-tools/siin/terp 

Modified Files: 
execute . c 
Log Message: 

- Added new variables last_regs and last_thread, which are used to track the most recent 
instruction which modified a register. 

- Clear those two variables if the call to sim_load_store () returned a failure status. 

- Before leaving, if last_regs is not NULL, do the register commit trace. 
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From: 
Sent: 
To: 

Subject: 


lisa 

Wednesday, November 02, 1994 1:26 PM 
'software-checkins-dist' 
gnu-tools/sim/terp cycles.c 


Update of /p/cvaroot/gnu-tools/sitn/terp 

In directory calliope: /N/auspex/roct/s6/lisa/src/gnu-tools/sini/terp 

Modified Files: 
cycles . c 
Log Message : 

When turning tracing on for the first time, clear last_regs and last_thread. 
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From: lisa 

Sent: Wednesday, November 02, 1 994 1 :44 PM 

To: 'software-checkins-dist' 

Subject: gnu-tools/sim/terp execloop.c 


update of /p/cvsroot /gnu- tools/ Sim/ terp 

In directory calliope: /N/auspex/root/s6/lisa/src/gnu-tools/sim/terp 

Modified Piles: 

execloop.c 
Log Message: 

- Removed check of dcachep->needs_copy; gave up on this optimization. 

- When cache tag becomes dirty, record the tag write for hazard detection. 

- When data_access{) returns failure status, clear last_regs/last_thread. 

- Changed E_TPROT exceptions to F_IFETCH or F_BRANCH, depending on context, 
so that the real exception is given from within insn_f etch () . 

- Near top of loop, trace the register commit for the previous instruction 
(if last_regs is not NULL) . 

- When updating register scoreboards for current instruction's destination (s) , 
record current reg_ptrs and thread in last_regs and last_thread. 

- Moved check of hth_da_incomplete so that we don't miss any cycle- counting 
code -- just want to avoid (re- ) coiinting the instruction. 
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From: 
Sent: 

To: 

Subject: 


lisa 

Wednesday, November 02, 1994 1:57 PM 
'software-checkins-dist' 
gnu-tools/sim/terp memory. h 


Update of /p/cvsroot /gnu-tools/sim/terp 

In directory calliope: /N/auspex/root/s6/lisa/src/gnu-tools/sim/terp 

Modified Files: 
memory . h 
Log Message: 

- Removed dcache field needs_copy; gave up on this optimization. 

- Removed the nb-structure fields nb_rdep and nb_rdepl; more info is now 
provided by nb_regs (which includes register pointers, dependencies, etc) . 
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From: 
Sent: 
To: 

Subject: 


llsa 

Wednesday, November 02, 1994 1:57 PM 
'software-checkins-dlsf 
gnu-tools/sim/terp memory.c 


Update of /p/cvsroot /gnu-tools/sim/terp 

In directory calliope : /N/auspex/root/s6/lisa/src/gnu-tools/sim/terp 

Modified Files: 
memory . c 
Log Message: 

- Fixed the (incorrect) calculation of the total size of the cache tags. 

- Removed implementation of dcachep->needs_copy; gave up on this optimization. 

- When cache tag becomes dirty, record the tag write for hazard detection. 

- The nb- structure fields nb_rdep and nb_rdepl are superseded by the new 
field nb_regs? modified all related code accordingly. 

- When setting up the nb- structure for a non-blocking load, clear last_regs 
and last_thread (which were set in execute_loop ( ) ) -- the register commit 
will get traced later, in nb_access__alldone ( ) , when the load completes. 
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From: 
Sent: 
To: 


Subject: 


William Herndon [bill@polyhymnla] 
Wednesday, November 02, 1994 6:30 PM 

'tbr@polyhymnia'; 'geert@polyhymnia'; 'andrew@polyhymnla'; 'tvo@polyhymnia'; 
'mudge@polyhymnia'; 'tfk@po!yhymnia' 
current thru the power poles 


I did some calculations on the power thru the power poles. 

1. max possible current thru 1 pole at 1/5 power power poles are spaced every 5 atoms 
along a spar, there are two flavors. 

vdd and vss 

each flavor then services ten atom rows, at 1/5 power, each atom has the potential of 
lOua, and there are 237 atoms/row this leaves 2.37ma/row * 10 rows = 23.7ma max current 
per power pole 

2. I counted the power poles on euterpe: : 483 (a little less than 47 of these should 
possibly be excluded. . the point is the number is better than 10% 

accurate) 

since there are two flavors, 483/2=241 for each flavor power supply lead 
(vdd/ vss) 

The total nom power for euterpe is 55watts, 21 watts come from custom (non sofa stuff) 
this leave 34 watts for the sofa, reduced to 1/5 pwr this goes to 34/5=6 . 8watts, 
6 . 8watts/3 . 3v=2 . OSamps, 2, 060ma/241=8 . 54ma . 

are we really only using 8.54/23.7 = 0.36 of the available power ?? in the xlu it was 
close to 0.8 

I would like response to my numbers. Am i missing something?? if the numbers are ok then 
we need to respond to probe technology with. . 

current per pad = 8.5ma average 23.7ma max 

I think it makes more sense for me to feed andrew the numbers and have only one point of 
communication between ourselves and probe technology. 
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From: Loretta Guarino [guarino@MicroUnity.com] 
Sent: Wednesday, November 02, 1994 6:32 PM 

To: 'gmo@MicroUnity.com'; 'wayne@MlcroUnity.com'; 'jeffm@MicroUnity.com'; ■doi@MicroUnity.com'; 
'sandeep@MicroUnity.com'; 'gregg@MicroUnity.com' 

Cc: 'guarino@MicroUnity.com'; 'abbott@MicroUnity.com'; 'lisar@MicroUnity.com'; 
'mudge@MicroUnity.com'; *liestia@MicroUnity.com' 

Subject: bring-up meeting of November 2 

Next meeting: Nov, 9 at 10:00; we'll review the Euterpe 
Bring-up section of ttie schedule at this meeting. 

Johnny Mudge joined us for the first hour to 
discuss component testing of Calliope and Euterpe. 
Ultimately, Johnny's group will produce paclcaged chips with 
a data sheet that will be written as testing proceeds, 
Johnny's group will also produce information about each 
chip they test - namely, what works and what doesnt The 
test vectors will touch a large percentage of the 
functionality of Calliope and Euterpe. There is not yet a 
formal plan for these tests. Someone will 
either need to convert the verification group's dvts or 
write tests from scratch that generate vectors for the HP 
tester. Mark Warren is working on test vectors for 
Calliope, and will be looking at them for Euterpe. 

Johnny will provide us with a plan for the test vectors. 
(This is to be worked out between Mark's group and Lisa's 
group.) Johnny will also produce a plan for tracking 
individual components. 

Action item: determine whether we should interface Johnny's 
daughter card to our boards, or whether we can remove and 
resolder tab devices to the boards. (Wayne) 

Action item: develop plan for tracking individual components 
in verification: is the logbook sufficient? do we need 
a database system? how does it relate to Johnny's tracking 
plan? (Wayne, Derek) 

Review of old action items: 


> Define parallel interface (Wayne, Gmo, and Sandeep) 
Essentially done; Wayne will incorporate the description 
into the CBI document by Friday. 

> Implement parallel port device drivers for sun and 

> sgi (Sandeep, Derek) 

This will be postponed until after the remote gdb work, 
closer to when real hardware will be available. 

> Define the boot state for standalone tests (Jeff, Gmo) 
Done. New action item: write boot code (Gmo) 

> Write up a plan for virtual devices and their 
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> interaction with gdb (Gmo) 
In progress. 

> Build scripting/UI capabilities above gdb for 

> regression tests (Derek) 
No progress. 

> Create a separate tool for loading FlasliROM 

> (Unassigned) 

No progress [manufacturing issue]. 

> Implement remote gdb with the software simulator 
> (Sandeep) 

In progress. Current due date is November 9, although 
Sandeep discovered more v/aik than he expected. 

> Find out who is driving the characterization testing 

> of components, especially for Euterpe. (Loretta) 
Done, See summary at the beginning of this message. 

> Develop set of milestones and schedule for bring-up 

> (Wayne, Derdc, Loretta) 

Done. New action item: Get durations for events on the 
schedule (Derek) 

> Add the Verification group's test control document 

> to the bring-up plan. 
No progress. 

> Write a summary of the hardware bring-up process 

> to cross-check with Wayne's schedule (Jeff) 

Jeff obtained useful information from today's meeting, but 
needs some time with Wayne before he can write the summary. 

> Identify our bring-up tools and make sure we 

> have plans for how we will debug them. (Derek, et al) 
In progress. 

> Develop plan for testing real-time software before 

> the analog parts of calliope work. (Gregg) 

I talked with Gregg after the meeting. The most practical 
plan is to use Pandora when it is available to load data into 
Hestia memoiy. Other options seem like more work than they 
are worth. 

> Verify SN3. (Wayne) 
Done. 

Action items from the CBI interfece meeting: 


> Fmd out if it is a requirement for SD to *remain* low 

> for a reset (Wayne) 
Done. 

> Determine which pins can be software controlled on each 

> of the parallel ports we are planning to support 

> (Derek) 
No progress. 

> Ask Craig if an abort invalidates the byte in transit 

> or the entire packet. (Wayne) 
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No progress. 

> Undei^tand how interrupts are generated by the parallel 

> ports under consideration. (Sandeep, Derek) 
No progress. 

New action items: 

Create performance test plans (Jeff, Loretta) 

Add Unix<!ike tests to software acceptance tests. (Loretta) 
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From: Loretta Guarlno [guarino@thessalus.microunlty.com] 

Sent: Wednesday, November 02. 1994 6:32 PM 

To: 'gmo@thessalus.microunity.com'; 'wayne@thessalus.microunity.com'; 

•jeffm@thessalus.microunity.com'; 'doi@thessalus.microunlty.com'; 

'sandeep@thessalus.microunity.com'; 'gregg@thessalus.microunity.com' 
Co: 'guarino@thessalus.microunity.com'; 'abbott@thessalus.microunity.com'; 

'lisar@thessalus.microunity.com'; 'mudge@thessalus.microunity.com'; 

'hestta@thessalus.microunity.com' 
Subject: bring-up meeting of November 2 


Next meeting: Nov. 9 at 10:00; we'll review the Euterpe Bring-up section of the schedule 
at this meeting. 

Johnny Mudge joined us for the first hour to discuss component testing of Calliope and 
Euterpe , 

Ultimately, Johnny's group will produce packaged chips with a data sheet that will be 
written as testing proceeds, 

Johnny's group will also produce information about each chip they test ~ namely, what 
works and what doesn't. The test vectors will touch a large percentage of the 
functionality of Calliope and Euterpe. There is not yet a formal plan for these tests. 
Someone will either need to convert the verification group's dvts or write tests from 
scratch that generate vectors for the HP tester. Mark Warren is working on test vectors 
for Calliope, and will be looking at them for Euterpe. 

Johnny will provide us with a plan for the test vectors. 
(This is to be worked out between Mark's group and Lisa's 

group.) Johnny will also produce a plan for tracking individual components. 

Action item: determine whether we should interface Johnny's daughter card to our boards, 
or whether we can remove and resolder tab devices to the boards. (Wayne) 

Action item: develop plan for tracking individual components in verification: is the 
logbook sufficient? do we need a database system? how does it relate to Johnny's tracking 
plan? (Wayne, Derek) 

Review of old action items: 


> Define parallel interface (Wayne, Gmo, and Sandeep) Essentially done; Wayne will 
incorporate the description into the CBI document by Friday. 

> Implement parallel port device drivers for sun and 

> sgi (Sandeep, Derek) 

This will be postponed until after the remote gdb work, closer to when real hardware will 
be available. 

> Define the boot state for standalone tests (Jeff, Gmo) Done. New action item: write 
boot code (Gmo) 

> Write up a plan for virtual devices and their 

> interaction with gdb (Gmo) 
In progress. 

> Build script ing/UI capabilities above gdb for 

> regression tests (Derek) 
No progress. 

> Create a separate tool for loading FlashROM 

> (Unas signed) 

No progress [manufacturing issue] , 

> Implement remote gdb with the software simulator 

> (Sandeep) 

In progress. Current due date is November 9, although Sandeep discovered more work than he 
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es^ected. 


> Find out who is driving the characterization testing 

> of components, especially for Euterpe. (Loretta) Done. See summary at the beginning 
of this message . 

> Develop set of milestones and schedule for bring-up 

> (Wayne, Derek, Loretta) 

Done. New action item: Get durations for events on the schedule (Derek) 

> Add the Verification group's test control document 

> to the bring -up pleui. 
No progress. 

> Write a summary of the hardware bring-up process 

> to cross-check with Wayne's schedule (Jeff) Jeff obtained useful information from 
today's meeting, but needs some time with Wayne before he can write the summary. 

> Identify our bring -up tools and make sure we 

> have plans for how we will debug them. {Derek, et al) In progress. 

> Develop plan for testing real-time software before 

> the analog parts of calliope work. (Gregg) I talked with Gregg after the meeting. 
The most practical plan is to use Pandora when it is available to load data into Hestia 
memory. Other options seem like more work than they are worth. 

> Verify SN3 . (Wayne) 
Done. 

Action items from the CBI interface meeting: 


> Find out if it is a requirement for SD to *remain* low 

> for a reset (Wayne) 
Done. 

> Determine which pins can be software controlled on each 

> of the parallel ports we are planning to support 

> (Derek) 
No progress. 

> Ask Craig if an abort invalidates the byte in transit 

> or the entire packet. (Wayne) 
No progress. 

> Understand how interrupts are generated by the parallel 

> ports under consideration. (Sandeep, Derek) No progress. 


New action items: 


Create performance test plans (Jeff, Loretta) 

Add Unix- like tests to software acceptance tests. (Loretta) 
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From: 
Sent: 
To: 

Subject: 


Buffalo Chip [chip@rhea] 

Wednesday, November 02, 1994 7:23 PM 

'geert@rhea' 

pager log message 


page from chip to geert : 

Release euterpe/verilog/bsrc/cc BOM 23 . 0 initiated by dickson completed ® Wed Nov 2 
16:20:36 PST 1994 with exit Status 0.. chip 

all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
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From: Lisa Robinson [lisar@polyhymnia] 

Sent: Wednesday, November 02. 1994 8:14 PM 

To: 'craig@polyhymnia'; 'lisar@polyhymnia' 

Subject: Registered copy generated 


Copy created by; lisar 

Copy created at: Wed Nov 2 17:13:38 PST 1994 

Copy number: 281 

Copy registered to: Manoj Puri 

Input file: 

/u/ craig/docuraents/Terpsichore/Terpsichore . macps . gz . des 

Output file: /u/craig/documents/Terpsichore/Terpsichore .ps 

Printed to: rsh plotter Ipr -PCraig 

Recorded in file: /u/craig/documents/RegistrationLog 

[This message generated by /u/craig/bin/macpstops] 
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From: 
Sent: 
To: 

Subject: 


Lisa Robinson [lisar@polyhymnia] 
Wednesday, November 02, 1994 8:36 PM 
'craig@polyhymnia'; 'lisar@po(yhymnia' 
Registered copy generated 


Copy created by: lisar 

Copy created at: Wed Nov 2 17:35:45 PST 1994 

Copy number: 281 

Copy registered to: Manoj Puri 

Input file: 

/u/craig/documents/Terpsichore/Terpsichore . macps . gz . des 

Output file: /u/craig/documents/Terpsichore/Terpsichore .ps 

Printed to: rsh plotter Ipr -PCraig 

Recorded in file: /u/craig/documents/RegistrationLog 


[This message generated by /u/craig/bin/niacpstops] 
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From: 


tbr 


To: 


Sent: 


Subject: 


Wednesday, November 02, 1994 9:30 PM 
'lisar- 

forwarded message from Geert Rosseel 


Follow Up Flag: Follow up 
Flag Status: Red 

Start of forwarded message 

Return-Path: <geert@ambiorix> 

Received: from ambiorix.microunity.com by gaea.microunity.com (4.1/musel.3) 

id AA06461; Tue, 1 Nov 94 23:20:25 PST 
Received: from localhost by ambiorix.microunity.com (8.6.4/muse-sw.2) 

id XAA01534; Tue, 1 Nov 1994 23:20:23 -0800 
Message-Id: <19941 1020720,XAA01534@ambiorix.microuni1y.com> 
From: geert@ambiorix (Geert Rosseel) 
To: tbr@ambiorix 

Subject: elib : found the problem me not crazy, just confused. 
Date: Tue, 1 Nov 1994 23:20:23 -0800 


Hi Tim, 

I was looking in : 

/n/auspex/s4 1 /euterpe-proteus/proteus 
Apparently that is different from : 
/n/auspex/s4 1 /euterpe-snapshot/euterpe/proteus 

I though that Lisa had said that these two were linked together and were the same thing 
When I do an Is in /n/auspex/s41/euterpe-proteus/jproteus/verilog 


I get: 


BOM 

BOM.BAK 
CVS 


Makefile dclib 

cerbmaster diff.h 
clib dxlib HI 


eclib 


mlib 


xlib 
zblib 
zblibsrc 


zclib 


exlib 


src 


zeblib 


libsrc 


wrappers 


zxlib 


NO elib or delib ... 


Geert 

End of forwarded message 
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Subject: 


From: 
Sent: 


To: 


Cc: 


tbr 

Wednesday, November 02, 1994 9:31 PM 

'Geert Rosseel' 

'geerf 

elib : found the problem me not crazy, just confused. 


Follow Up Flag: Follow up 
Flag Status: Red 

Geert Rosseel wrote (on Tue Nov 1): 

Hi Tim, 

I was looking in : 

/ii/auspex/s4 1 /euterpe-proteus/proteus 
Apparently that is different from : 
/n/aiispex/s4 1 /euteipe-snapshot/euterpe/proteus 

I though that Lisa had said that these two were linked together and were the same thing 

Clearly they are not the same. 1 copied lisar on our mail so we can 
figure out what's going on. I assume that one copy is the version 
taken by tar, and the other the one she was building from cold. 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Tim B. Robinson [tbr@aphrodite] 
Wednesday, November 02, 1994 9:31 PM 
'Geert Rosseel' 
'geert@aphrodite' 

elib : found the problem .. me not crazy, just confused. 


Geert Rosseel wrote {on Tue Nov 1) : 
Hi Tim, 

X was looking in : 

/ n/ auspex / s4 1 / eut e rpe - pr ot eu s / prot eus 
Apparently that is different from : 

/n/auspex/ s4 1 / euterpe - snapshot / euterpe / prot eus 
I though that Lisa had said that these two were linked together and were the same 


Clearly they are not the same . I copied lisar on our mail so we can figure out what ' s 
going on. I assume that one copy is the version taken by tar, and the other the one she 
was building from cold. 


thing 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Tim B. Robinson [tbr@aphroclite] 
Wednesday, November 02, 1994 10:12 PM 
'William Hemdon' 

'andrew@polyhymnla': 'geert@polyhymnia'; 'mudge@polyliymnia'; 'tfk@polyhymnia'; 

'tvo@polyliymnla' 

cun'ent thru tlie power poles 


William Hemdon wrote (on Wed Nov 2) : 

I did some calculations on the power thru the power poles. 

1. max possible current thru 1 pole at 1/5 power 

power poles are spaced every 5 atoms along a spar, there are two flavors, vdd and vss 
each flavor then services ten atom rows, at 1/5 power, each atom has the potential of 
lOua, and there are 237 atoms/row 

this leaves 2.37ma/row * 10 rows = 23.7ma max ciirrent per power pole 

2. I counted the power poles on euterpe : : 483 (a little less than 47 of these should 
possibly be excluded. . the point is the number is better than 10% 

accurate) 

since there are two flavors, 483/2=241 for each flavor power supply lead (vdd/vss) 
The total nora power for euterpe is 55watts, 21 watts come from custom (non sofa stuff) 
this leave 34 watts for the sofa, reduced to 1/5 pwr this goes to 34/5=6 . Swatts, 
6 . 8watts/3 .3v=2 . 06amps, 2, 060ma/241=8 . 54ma . 

are we really only using 8.54/23.7 = 0.36 of the available power 7? in the xlu it was 
close to 0.8 

My guess would have been 0.6. if geert has a top level topt log file we can find the 
exact number. 

I would like response to my numbers. Am i missing something?? if the numbers are ok 
then we need to respond to probe technology with. . 

current per pad = 8 . 5ma average 23 . 7ma max 

X think it makes more sense for me to feed andrew the numbers and have only one point 
of commimication between ourselves and probe technology. 

If you already know the number is 0.8 in the XLU, then clearly we have local areas where 
we may be well above the average. Should we be making the worst case assumption? 
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From: Lisa Robinson [llsar@nosferatu] 

Sent: Wednesday, November 02, 1994 10:21 PM 

To: 'Tim B. Robinson'; 'geert@nosferatu' 

Cc: 'hopper@nosferatu'; 'tom@nosferatu'; 'brian!@nosferatu'; Vant@nosferatu'; Vo@nosferatu' 

Subject: forwarded message from Geert Rosseel 


Tim B. Robinson wrote (on Wed Nov 2) ; 

Start of forwarded message 

Return- Path: <geert@anibiorix> 

Received: from ainbiorix.Tnicrounity.com by gaea.microunity.com 

{4 .l/musel.3) 

id AA06461; Tue, 1 Nov 94 23:20:25 PST 
Received: from localhost by ambiorix.microunity.com (8 . 6 . 4/muse-sw. 2) 

id XAA01534; Tue, 1 Nov 1994 23:20:23 -0800 
Message -Id: <19 94 11020720 . XAA0l534@ambiorix.microunity . cora> 
From: geert@ambiorix (Geert Rosseel) 
To : tbr@ambiorix 

Subject: elib : found the problem .. me not crazy, just confused. 
Date: Tue, 1 Nov 1994 23:20:23 -0800 

Hi Tim, 

I was looking in : 

/n/auspex/s41/euterpe-proteus/proteus 
Apparently that is different from : 
/n/auspex/s4l/euterpe-snapshot/euterpe/proteus 

I though that Lisa had said that these two were linked together and were the same 

thing 

When I do an Is in /n/auspex/s41/euterpe-proteus/proteus/verilog 
I get : 

BOM Makefile dclib eclib ml lb 

xlib zclib 

BOM.BAK cerbmaster diff.h exlib src 

zblib zeblib 

CVS clib dxlib libsrc 

wrappers zblibsrc zxlib 

NO elib or delib ... 


Geert 

End of forwarded message 


Its a long story 


I was building an proteus from scratch in /n/auspex/s41/euterpe-proteus/proteus 

but brianl needed to rerun in /u/chip so we stopped the s4l build and instead took a tar 

image of /u/chip so as not to hold up the snapshot 

- remember we discussed it. Tom put this on /n/auspex/s23/euterpe-proteus-cp . 

Then I needed some space to do the euterpe build so I made a euterpe in the euterpe- 
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proteus and asked torn to rename euterpe-proteus to euterpe - snapshot , 

Howver since he didn't want to mess up work in progress he just symbolically linked it to 
euterpe-snaphot . The proteus used by the euterpe build does NOT point at ../proteus since 
that is not the snapshot proteus but to /n/auspex/s23 . . . . 

I am still waiting for the go ahead from brian to restart the build from scratch proteus 
build which will probably be done somewhere else so as not to fill up /s41. 

I will remove the dinosaur proteus in /s41. 


Lisa R. 
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From: tbr 

Sent: Wednesday. November 02, 1994 1 1 :05 PM 

To: 'Lisa Robinson' 

Cc: 'brianl@nosferatu'; 'geert@nosferatu'; 'hopper@nosferatu'; 'tom@nos1eratu'; 

Vant@nosferatu'; Vo@nosferatu' 

Subject: forwarded message from Geert Rosseel 

Follow Up Flag: Follow up 

Flag Status: Red 


Lisa Robinson wrote (on Wed Nov 2): 


Its a long story 


I was building an proteus from scratch in 
/n/auspex/s4 1 /euterpe-proteus/proteus 

but briani needed to rerun in /u/chip so we stopped the s41 build and 
instead took a tar image of /u/chip so as not to hold up the snapshot 
- remember we discussed it. Tom put this on 
/n/auspex/s23/euterpe-proteijs-cp. 

Then I needed some space to do the euterpe build so I made a euterpe in 
the euterpe-proteus and asked tom to rename euterpe-proteus to 
euterpe-snapshot. 

Howver since he didn't want to mess up work in progress he just 

symbolically linked it to euterpe-snaphot. The proteus used by the 

euterpe build does NOT point at ../proteus since that is not the 

snapshot proteus but to /n/auspex/s23.... 

I am still waiting for the go ahead from brian to restart the build 

from scratch proteus build which will probably be done somewhere else 

so as not to fill up /s41. 

Glad someone knows what's going on! 
Tim 
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Subject 


From: 
Sent: 
To: 
Cc: 


Tim B. Robinson [tbr@aphrodite] 
Wednesday, November 02, 1994 11:05 PM 
'Lisa Robinson' 

•brlanl@nosferatu'; 'geert@nosferatu'; 'hopper@nosferatu'; 'tom@nosferatu'; 
'vant@nosferatu'; 'vo@nosferatu' 
forwarded message from Geert Rosseel 


Lisa Robinson wrote (on Wed Nov 2) : 


Its a long story 


I was building an proteus from scratch in 
/n/auspex/ s4l/euterpe -proteus /proteus 

but brianl needed to rerun in /u/chip so we stopped the s41 build and 
instead took a tar image of /u/chip so as not to hold up the snapshot 
- remember we discussed it . Tom put this on 
/n/auspex/s23/euterpe-proteus-cp. 

Then I needed some space to do the euterpe build so I made a euterpe in 
the euterpe -proteus and asked torn to rename euterpe -proteus to 
euterpe - snapshot . 

Howver since he didn't want to mess up work in progress he just 
syaibolically linked it to euterpe- snaphot . The proteus used by the 
euterpe build does NOT point at . . /proteus since that is not the 
snapshot proteus but to /n/auspex/ s23 ... . 

I am still waiting for the go ahead from brian to restart the build 
from scratch proteus build which will probably be done somewhere else 
so as not to fill up /s41. 

Glad someone knows what's going on! 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Mark Hofmann [hopper@boreas] 
Wednesday, November 02, 1994 11:14 PM 
Tim B. Robinson' 

'lisar@nosferatu'; 'brianl@nosferatu'; 'geert@nosferatu'; 'hopper@nosferatu'; 
'tom@nosferatu'; Vant^nosferatu'; 'vo@nosferatu' 
Re: forwarded message from Geert Rosseel 


Tim B. Robinson writes: 

Lisa Robinson wrote (on Wed Nov 2) : 
Its a long story 


I was building an proteus from scratch in 
/n/auspex/s4l/euterpe-proteus/proteus 

but brianl needed to rerun in /u/chip so we stopped the s41 build and 
instead took a tar image of /u/chip so as not to hold up the snapshot 
- remember we discussed it. Tom put this on 
/n/auspex/ s23 /euterpe-proteus - cp . 

Then I needed some space to do the euterpe build so I made a euterpe in 
the euterpe-proteus and asked torn to rename euterpe-proteus to 
euterpe- snapshot . 

Howver since he didn't want to mess up work in progress he just 
symbolically linked it to euterpe- snaphot . The proteus used by the 
euterpe build does NOT point at . . /proteus since that is not the 
snapshot proteus but to /n/auspex/s23 . . . . 

I am still waiting for the go ahead from brian to restart the build 
from scratch proteus build which will probably be done somewhere else 
so as not to fill up /s41. 

Glad someone knows what's going onl 


Would larger partitions (> 2gb) be a help here? Tim- have the sysadms gotten a definitive 
answer on this one? It seems to me that once we have 9Gb disks it will be terribly 
inefficient to be tied to 2Gb partitions. 


Tim 


-hopper 
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From: Geert Rosseel [geert@rheaj 

Sent: Wednesday, November 02, 1 994 1 1 :24 PM 

To: 'geert@rhea' 

Subject: pager log, sender copy 


page from geert to geert: 

pageme gmake gards/geert_euterpe- iter .garout . lis start :Nov_02_19 : 10 end: 
Nov 02 20:22 exit 0 
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From: tbr 

Sent: Wednesday, November 02, 1 994 1 1 :36 PM 

To: 'Mark Hofmann' 

Cc: 'brjanl@nosferatu'; 'geert@no5feratu'; 'hopper@nosferatu'; 'ljsar@nosferatu'; 

'tom@nosferatu'; 'vant@nosferatu': 'vo@nosferatu' 

Subject: Re: forwarded message from Geert Rosseel 

Follow Up Flag: Follow up 

Flag Status: Red 


Mark Hofinann wrote (on Wed Nov 2): 

Tim B. Robinson writes: 
Lisa Robinson wrote (on Wed Nov 2): 
Its a long stoiy 


I was building an proteus from scratch in 
/n/auspex/s4 1 /euterpe-proteus/proteus 

but brianl needed to rerun in /u/chip so we stopped the s41 build and 
instead took a tar image of /u/chip so as not to liold up the snapshot 
- remember we discussed it. Tom put this on 
/n/auspcx/s23/euterpe-proteus-cp. 

TTien I needed some space to do the euterpe build so I made a euterpe in 
the euterpe-proteus and asked torn to rename euterpe-proteus to 
euterpe-snapshot. 

Howver since he didn't want to mess up work in progress he just 

symbolically linked it to euterpe-snaphot The proteus used by the 

euterpe build does NOT point at ../proteus since that is not the 

snapshot proteus but to /n/auspex/s23.,., 

I am still waiting for the go ahead from brian to restart the build 

from scratch proteus build which will probably be done somewhere else 

so as not to fill up /s41. 

Glad someone knows what's going on! 
Tim 

Would larger partitions (> 2gb) be a help here? Tim- have the sysadms gotten a 
definitive answer on this one? It seems to me that once we have 9Gb disks 
it will be terribly inefficient to be tied to 2Gb partitions. 

No, but as soon as we have the new disks in some experiments will be 
done. 

Tim 
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From: Mark Hofmann [hopper@boreas] 

Sent: Wednesday. November 02. 1 994 11 :59 PM 

To: Tim B. Robinson' 

Subject: Re: forwarded message from Geert Rosseel 

Tim B. Robinson writes: 

The only problem is if the O/S insists on counting bytes, then 2^3 1 = 2Gb 
is a limit. However, partitions are block-oriented things (where a 
block is usually Ik or 4k bytes) so, in theory, the O/S should be able 
to address at least 2Terabytes without a problem. 

Well, the bsd file system supports 512B fragments, so I think that* s 
the basic unit, but even so, it gives another 9 bits of address. 

Which should hold us at least until Euterpe III 

-hopper 
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From: 


tbr 


To: 


Sent: 


Subject: 


Thursday, November 03, 1994 12:01 AM 
'Mark Hofmann" 

Re: forwarded message from Geert Rosseel 


Follow Up Flag: Follow up 
Flag Status: Red 

Mark Hofmann wrote (on Wed Nov 2): 

Tim B. Robinson writes: 

The only problem is if the 0/S insists on counting bytes, then 2^3 1 = 2Gb 
is a limit. However, partitions are block-oriented things (where a 
block is usually Ik or 4k bytes) so, in theory, the O/S should be able 
to address at least 2Terabytes without a problem. 

Well, the bsd file system supports 512B fragments, so I think that's 
the basic unit, but even so, it gives another 9 bits of address. 

Which should hold us at least until Euterpe III 

Yes. Actually, I think there used to be an issue with backup with big 
partitions. I'm not sure if that was because of 2GB tape capacity 
or because they used to use mirrored partitions, but now we use 5GB 
tapes so that limit should have gone up. As far as I know dump 
handles multivolume dumps OK anyway. 


Tim 
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From: Buffalo Chip [chip@rhea] 

Sent: Thursday. November 03, 1994 12:30 AM 

To: 'geert@rhea' 

Subject: pager log message 


page from chip to geert : 

Release euterpe/verilog/bsrc/lt BOM 67.0 initiated by woody completed @ Wed Nov 2 21:29:25 
PST 1994 with exit status 0.. chip 
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From: JayTomlinson [woody@luckboy] 

Sent: Thursday, November 03, 1 994 1 1 :28 AM 

To: 'euterpe@luckboy' 

Subject: IMMINENT Decision: Instruction cache tag bit change 


The current micro-arch doc defines the bits of the instruction cache tag as 
follows : 

bit meaning 

7 Caching control, exception 3 if set 

6 Detail access, exception 2 if set 
5 . . 2 ignored by hardware 

1..0 Execution access, causes exception 1 if > privilege level 

I propose changing the location of the Execution Access field to allow the hardware to use 
bit 0 as a valid bit (bit 0 of the data cache tag is the defined as the dirty-bit) . This 
change would speed up the I-cache raiss processing by allowing the hardware to invalidate 
the tag entry without having to write the entire entry. This change will also simplify the 
euterpe hardware. The tag array has a write-enable for this bit. 

My proposal for the new bit definitions is: 

bit meaning 

7 Caching control, exception 3 if set 
6 Detail access, exception 2 if set 

5 . . 4 ignored by hardware 

3.. 2 Execution access, causes exception 1 if > privilege level 
1 ignored by hardware 

0 valid 

This change will become final at 11:59PM Monday, Nov 7, 1994. 

Objections should be sent out immediately and can be reviewed Friday /Monday. 

Jay 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Patricia Mayer [pmayer@ luck boy] 
Thursday, November 03, 1994 12:05 PM 
'hestia@aphrocllte'; 'tbr@aphrodite' 
'pmayer@aphrodite'; 'albers@aphrodite'; 'philip@aphrodite' 
Re: prl review 


> From tbr@aphrodite Sat Oct 29 17:53:44 1994 

> Date: Sat, 29 Oct 1994 17:53:38 -0700 

> From: tbr®aphrodite (Tim B. Robinson) 

> To: hestia@aphrodite 

> Cc: pmayerOaphrodite, albers®aphrodite, tbrOaphrodite , 

> philip@aphrodite 

> Subject: prt review 

> Content -Length: 1798 


> Notes from the main board prt review 
> 

> 1. All SMT components need pad dimensions checking. The PCAD report 

> does not include this information. It will have to be checked on 

> screen. Since glen built all these parts, pmayer will do the onscreen 

> check so it ' s independent . 

> 

> Action: pmayer to check pad dimensions for all the SMT parts in this 

> batch 

DONE - Fo-und a few problems. Used a PCAD Materials list from the Main PWB. 
Does anybody need plots? 


> 2. pmayer noted that PCAD requires an explicit upodate if a library 

> part is changed. Since there have been so many changes it would be 

> worth investigating if there is a way to re-read the entire library. 
> 

> Action: tbr to ask albers to check if we can do a global update. If 

> not, pmayer will update components individually, 

> 

Dan did figure out a way to do this globally. THANKS! 
> 

> 3 . It would be helpful for pmayer to receive the checkin notices for 

> the library. 
> 

> Action: tbr to have torn add her to the distribution. (Done) 

> 

Receiving 
> 

> 4. pl00_00005, pll0_00028 

> These parts do not have pin 1 distinguished by pad shape. 
> 

> Action: pmayer to correct. 
> 

Chopped pin one in parts: 

pllO_OOOC4 

pllOOOOOS 

pll0_00006 

pll0_00006 

pll0_00008 

.pll0_00013 

pllO_00017 

pll0_00019 

pll0_00021 

pll0_00028 

pl80_00004 

p370 00004 


Exhibit C8 


Page 96 of 598 


Used my material list and chopped all pin ones that were in a semetrical footprint. 

> 

> 5. pllO_00029 

> There was confusion over the preferred vendor for this part. The 

> database has National, but according to yves it's not in their data 

> book. 

> 

> Action: philip to resolve preferred vendor. 
> 

> 6. pll0_00031 

> The hole size is too large and could alow the shouldered portion of 

> the leads to drop right into the board. Hole size to be reduced 5 

> mils. New padstack is 
> 

> pin 1 113 

> pin 2 114 

> pin 3 114 

> 

> Action: pmayer to correct. 
> 

Done - Is this part used on the Main PWB? wasn't on my Material List 

> 

> 7. pl40_00010 

> Pin 2 needs to be pad type 114 (round pad) . 
> 

> Action: pmayer to correct. 
Done 

> 

> 8. pl80_00004 

> Some ground vias need position adjustment. 

> 

> Action: pmayer to correct. 
Done 

> 
> 

> 9. p210_00023, p210_00024 

> Pin 1 needs silk screen polarity indicator. Pins are reversed in .prt 

> file. 

> 

> Action: pmayer to correct. 
Done 

> 

> Tbr had to leave the meeting at this point. Woody will post notes on 

> on remaining issues. 


Another part issue that Philip mentioned was a fuducial mark for Caliope and Euterpe. ?? 
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From: 
Sent: 
To: 

Subject; 


Gregg Kellogg [gregg@hts.microunity.coml 
Thursday, November 03, 1994 12:14 PM 
'Brendan Elch' 

Re: == gmake -k in /p/soft/stb/terp-src/stb failed, see /p/sofVstb/terp-src/,stb-log == 


It occured to me last night that I might have forgotten to check this file in. 

That's a good idea about allocating a jmp_tiuf on the stack and pointing to it from one of 
the structures. 

I prefer moving the error_label from mpeg_decoder to mpeg_unpack:er . 

The primary purpose of the special case in the default error handler is for documentation. 
I don't expect that the default error handler will actually be used for production, it's 
primary purpose is as a debug aide. 


Gregg Kellogg 

MicroUnity Systems Engineering, Inc. 

2 55 Caspian Drive, Sunnyvale, Ca 94 0 8 9-1015 gregg@microunity.com 
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From: 
Sent: 
To: 

Subject: 


Geert Rosseel [geert@ambiorix] 
Thursday, November 03, 1994 1:24 PM 
'hardheads@ambiorlx' 

IMMINENT DECISION : change In pad-assignment 


Hi, 


Two decision were made related to power distribution on Calliope and Euterpe 


1 , Calliope 

We will connect the SENSE pad to the sealring. Currently, it is 
hooked up to the M3 layer (VDDE) on the space transformer, but the 
corresponding pad on the die is not hooked up to VDDE. We will 
now connect the die-pad to the seal-ring (also VDDE) in order to 
create another VDDE pad and reduce IR drops during test. 

2 . Euterpe 

We will change the power -pad asignment : currently we have VDDE on 
top and bottom and VSS on the sides. 

At the top and bottom, every other VDDE pad will be changed to a VSS 
pad. We need the VSS connections to provide power to the DRAM drivers. 

On the sides, spare pads used to be assigned to VSS. Now, every other 
pad will be VDDE. The reason is the same as for Calliope : 
reduce IR drop during test. 

None of these changes should affect the Tab- frame or board design. 
All VSS pads are always changed to VDDE pads on the space -transfromer. 


Geert 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Gregg Kellogg [gregg@hts.microunity.coml 
Thursday, November 03, 1994 2:00 PM 
'Brendan Eich' 
'fur' 

mpeg_unpack/decode issues 


For Scott's benefit. My reply to your latest message appended at the bottom. 


On Nov 2, 10: 4 Spin, Brendan Elch wrote: 

> Subject: Re: gtnake -k in /p/sof t/stb/terp-src/stb failed, see 

/p/soft/ 

> Rather than check in -gregg/stb/lib/mpeg/system/unpacker.h and restart 

the 

> build, I thought I'd better leave it to you to decide what's best. 

> From 

what 

> is checked in, it seems every unpacker {audio and video) will need a 

j rap_buf 

> member, whether useful or not. The trouble is jmp__buf is big, and it 
may not 

> always be valid. 
> 

> I ran into these problems already in video error recovery, which is 

> why mpeg_decoder_t has an error_label member (it is void * to avoid 
including 

> <setjmp.h> without really needing it). 

> Only if the error__label is non-null will 

> video. c:perform_error_recovery longjmp through it. The pointed-at 

> jmp_buf is allocated on the stack 

(only 

> on those stacks that need it, rather than in every unpacker) . Until 
setjmp 

> has been called, error_label is null. When control flows out of the 
function 

> in which setjmp was called, error_label is cleared, so no longjmp to a 
stack 

> variable that ' s been deallocated and possibly overwritten can occur 
(lack of 

> this was a bug 1 just fixed) . 

> We could move error_label from rapeg_decoder_t to mpeg_unpacker_t, and 
change 

> pat.c to point it at a local jrapbuf only after setjmp has returned 0. 
> 

> Or pat.c could use its own error callback instead of putting a special 
case 

> in the default callback, and this pat_error callback could longjmp 
through a 

> jmp_buf defined in the program structure, or mpeg_coroutine_t , or 
someplace 

> appropriate to the PSI decoders. I prefer this solution. 


>-- End of excerpt from Brendan Eich 


On Nov 3, 10; 26am, Brendan Eich wrote: 

> Subject: Re: == graake -k in /p/sof t/stb/terp-src/stb failed, see 
/p/sof t/s 

> To minimize cache working sets, PSI error handling should go in its 


Gregg 


> 


> /be 


> 
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> own callback, not in video's or audio's. Any documentary advantage to 

making 

> an all-in-one default callback now shouldn't expose PSI-specific data 

> to unpacker.c later, after the PSI-specific code has been removed. 
> 

> That said, if we do agree to move error_label to mpeg_unpacker_t , then 

> rapeg_decoder_t becomes even more "thin" and the thought of unifying 

> the two (mpeg_system_decoder_t? ) arises. The current separation has a 

> small simplifying effect on unpacker. [ch] , letting it focus on parsing 

> and so on, but not worry about queue attaching, buffer and error label 

> state, etc. There used to be more to do in decoder. c, so this effect 

> is less now than before. 
> 

> More significant: should mpeg_acquire j>at and other PSI functions use 

> nipeg_decoder_t ? Their caller will presumably need to keep track of an 

> UNCACHED qpieue buffer for PSI data. I.e., rapeg_acquire_pat and 

> similar future PSI coroutine entry points all take an mpeg_decoder_t * 

> as 

argument, 

> and use its error_label (or not) and local /appropriately- located 
jmp_buf s 

> in their own calback(s) . 
> 

> If the reason for moving error_label to mpeg_unpacker_t is the same as 

> the reason for having mpeg_decoder_t wrap mpeg_\Anpacker_t, and it 
applies 

> to the <3ueue_buffer as well, then PSI decoders should use 
n»peg_decoder_t . 

> 

> Whether to flatten unpacker and decoder is separable, and turns on how 

> much source complexity results. The data structure sizes probably 

> won't shrink by unification, and the decoder, c code is all init/free 

> time and not in any long-term cache working set. 

> 

> /be 
> 

>-- End of excerpt from Brendan Eich 

After looking the stuff over further, I'm inclined to agree with you that the PSI 
decode/error stuff is best handled in mpeg_decoder . 

This also simplifies the DEMUX code. 

Given that the PSI code sets up the error_label entry in mpeg_demux_t , it seems to me that 
there's no longer anything PSI specific about it: the error routine should simply longjrap 
through error_label on a hard-error when it's non-zero, but this code can now be moved 
into the mpeg_decode version of the error hcuadler. The default error case in the 
mpegdecode error handler should then do the appropriate fiinction and call the unpacker 's 
error code handler for more generic unpacker type things . 

I still maintain that any real code should provide it's own error handler, leaving the the 
default for stand-alone test use. 


Gregg Kellogg 

MicroUhity Systems Engineering, Inc. 

255 Caspian Drive, Sunnyvale, Ca 94089-1015 gregg®raicrounity . com 


Exhibit C8 


Page 101 of 598 


From: 

Sent: 
To: 

Subject: 


lisa 

Thursday, November 03, 1994 3:26 PM 
'software-checkins-dist' 
gnu-tools/sim/terp events.c 


Update of /p/cvsroot /gnu-tools/sim/terp 

In directory calliope: /N/auspex/root/sS/lisa/src/gnu-tools/sim/terp 

Modified Files: 
events . c 
Log Message : 

do_exception ( ) now takes an access type and, after encoding it, stores it in the access - 
mode field of the exception status. 
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From: 
Sent: 
To: 

Subject: 


lisa 

Thursday, November 03, 1994 3:28 PM 
'software-checkins-dist' 
gnu-tools/slm/terp memory, h 


Update of /p/cvsroot/gnu-tools/sira/terp 

In directory calliope : /N/auspex/root/s6/lisa/src/gnu-tools/sim/terp 

Modified Files: 
memory . h 
Log Message: 

- Fixed the length check in access_ptr and mem_j3tr. 

- Moved definition of atype_t from here into terp.h 

- Translation macros/ routines (e.g. lv_to_gv) now need the access_type. 

- Pass the access type to do_exception() , 
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From: 
Sent: 
To: 

Subject: 


lisa 

Thursday, November 03, 1994 3:29 PM 
'software-checkins-dist' 
gnu-tools/slm/terp terp.h 


Update of /p/cvsroot/gnu-tools/sim/terp 

In directory calliope : /N/auspex/root/s6/lisa/src/gnu- tools/ sim/terp 

Modified Files: 

terp. h 
Log Message: 

- Definition of atype_t moved into here (from memory. h) . 

- Modified declaration of do_exception ( ) -- added access_type parameter. 
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From: 
Sent: 
To: 

Subject: 


lisa 

Thursday, November 03, 1994 3:30 PM 
'software-checkins-disf 

gnu-tools/sim/terp decode.c execute.c v_mem.c 


update of /p/cvsroot /gnu-tools/sim/terp 

In directory calliope: /N/auspex/root/s6/lisa/src/gnu-tools/sim/terp 

Modified Files: 

decode.c execute.c v_TneTn.c 
Log Message: 

- Translation macros /routines {e.g. Iv to_gv) now need the access_type. 

- Pass the access type to do_exc6ption() . 
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From: 
Sent: 
To; 

Subject: 


lisa 

Thursday, November 03, 1994 3:32 PM 
'software-checkins-dist' 
gnu-tools/sim/terp memory. c 


Update of /p/cvsroot/gnu-toola/sim/terp 

In directory calliope: /N/auspex/root/s6/lisa/src/gnu-tools/sira/terp 

Modified Files: 
memory . c 
Log Message : 

- Put the real length of the tlb's in their access structures. 

- Translation macros /routines (e.g. lv_to_gv) now need the access_type. 

- Pass the access type to do_exception ( ) . 
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From: 
Sent: 
To: 

Subject: 


tisa 

Thursday, November 03, 1994 3:33 PM 
'software-checklns-d 1st' 

gnu-tools/si m/terp cerberus.c fp_support.c group.c hermes.c stbio.c 


update of /p/ cvsroot/ gnu- tools /sim/terp 

In directory calliope: /N/auspex/root/s6/lisa/src/gnu-tools/sim/terp 
Modified Files: 

cerberus.c fp_support.c group.c hermes.c stbio.c Log Message: 
- Pass the access type to do_exception ( ) . 


Exhibit C8 


Page 107 of 598 


From: 
Sent: 
To: 

Subject: 


lisa 

Thursday, November 03, 1994 3:33 PM 
'software-checkins-dist' 
gnu-tools/sim/terp/cailiope calliope.c 


Update of /p/cvsroot/gnu-tools/sitn/terp/calliope 
In directory 

calliope: /N/auspex/root/s6/lisa/src/gnu- tools/sim/terp/calliope 

Modified Files: 

calliope . c 
Log Message: 

- Pass the access type to do_exception() . 
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From: 
Sent: 
To: 

Subject: 


lisa 

Thursday, November 03, 1994 5:37 PM 
'Dave Conroy' 
Re: newterp 


> I see that a new sun terp is available. I am hoping that I am 

> accessing 

> it prior to its being fully built because I get a core dump when I run 

> it. I tried the dcachefunc and dcacheszlSk on it. 

Sorry, I just got back from lunch and two meetings. Are you still having trouble? I ran 
it with no problems , so if it is still crashing on you, please send me the exact command 
line and path so I can try it. 


lisa 
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From: 
Sent: 
To: 

Subject: 


andrew [andrew@charybdis] 

Thursday, November 03, 1994 5:45 PM 

'Geert Rosseel'; 'hardheads@charybdis' 

RE: IMMINENT DECISION : change In pad-assignment 


Geert 


So just to make sure I understand - On Calliope at WAFER SORT, the sense pad 

#52 that is currently a "no connect" needs to be connected to the Vdde power plane? 


Two decision were made related to power distribution on Calliope and Euterpe 


1. Calliope 

We will connect the SENSE pad to the sealring. Currently, it is 
hooked up to the M3 layer (VDDE) on the space transformer, but the 
corresponding pad on the die is not hooked up to VDDE. We will 
now connect the die-pad to the seal-ring (also VDDE) in order to 
create another VDDE pad and reduce IR drops during test. 

2 . Euterpe 

We will change the power -pad asignment : currently we have VDDE on 
top and bottom and VSS on the sides. 

At the top and bottom, every other VDDE pad will be chsmged to a VSS 
pad. We need the VSS connections to provide power to the DRAM drivers. 

On the sides, spare pads used to be assigned to vss. Now, every other 
pad will be VDDE. The reason is the same as for Calliope : 
reduce IR drop during test. 

None of these changes should affect the Tab- frame or board design. 
All VSS pads are always changed to VDDE pads on the space- transfromer. 


Andrew 


From: Geert Rosseel on Thu« Nov 3, 1994 10:25 AM 
Subject: IMMINENT DECISION : change in pad- assignment 
To : hardheads 


Hi, 


Geert 
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From: geert (Geert Rosseel) 

Sent: Thursday, November 03, 1994 7:15 PM 

To: 'bill'; 'geert'; 'vo'; 'wingard' 

Subject: MicroModule 


Hi, 


MicroModule will be here on Monday morning at 9:30 a.m.. They offer "silocon-on- 
substrate" packages (kind of a space- transformer without the airbridge) . We will probcUsle 
need something like this to get the power into our foundry Euterpe. 


If you want to come to this meeting, please do so. 


Geert 
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From: 
Sent: 
To: 

Subject: 


lisa 

Thursday, November 03, 1994 8:30 PM 
'softwa re-checki n s-d ist' 
gnu-tools/sim/terp memory, h memory. c 


Update of /p/cvsroot/gnu-tools/sim/terp 

In directory calliope: /N/auspex/root/s6/liaa/src/gnu-tools/sim/terp 

Modified Files: 

memory. h memory. c 
Log Message: 

Changed the nb_buf field from an array of bytes into a "real" hexlet, so that it has 


better alignment. 
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From: lisa 

Sent: Thursday, November 03, 1994 8:34 PM 

To: 'gmo' 

Subject: terp coredump on sun 


when I removed a field from the nb- access structure, the position change of the nb_buf 
array (within the structure) ran into alignment problems. (The bus error was from an 
unaligned access.) I just checked- in a fix (memory. h, memory. c). 

lisa 
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Sent: 
To: 

Subject: 


From: 


tbr 

Thursday, November 03, 1994 10:27 PM 
'Geert Rosseel' 

IMMINENT DECISION : change in pad-assignment 


Follow Up Flag: Follow up 
Flag Status: Red 

Geert Rosseel wrote (on Thu Nov 3): 


Hi. 

Two decision were made related to power distribution on Calliope and Euterpe 
1. Calliope 

We will connect the SENSE pad to the sealring. Currently, it is 
hooked up to the M3 layer (VDDE) on the space transformer, but the 
corresponding pad on the die is not hooked up to VDDE. We will 
now connect the die-pad to the seal-ring (also VDDE) in order to 
create another VDDE pad and reduce IR drops during test. 

What masks need to be remade to accomplish this? 


Tim 
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From: 
Sent: 
To: 

Subject: 


Tim B. Robinson [tbr@aphrodite] 
Thursday, November 03, 1994 10:27 PM 
'Geert Rosseel' 

IMMINENT DECISION : change in pad-assignment 


Geert Rosseel wrote (on Thu Nov 3) : 


Hi, 


Two decision were made related to power distribution on Calliope and Euterpe 


1. Calliope 

We will connect the SENSE pad to the sealring. Currently, it is 
hooked up to the M3 layer (VDDE) on the space transformer, but the 
corresponding pad on the die is not hooked up to VDDE, We will 
now connect the die-pad to the seal-ring (also VDDE) in order to 
create another VDDE pad and reduce IR drops during test . 

What masks need to be remade to accomplish this? 


Tim 
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From: Mark Hofmann [hopper@boreas] 
Sent: Thursday, November 03, 1994 10:57 PM 
To: 'Lisa Robinson' 

Cc: Tom Vo'; Tliomas Laidig'; 'Kurt Wampler'; 'vant@borea8'; Tim B. Robinson'; 'Geert Rosseei' 
Subject: Re: proteus reiease 

Lisa Robinson writes: 

I need to do two proteus releases, one in libsrc and one in misc. 
Unless I hear otiierwise, 111 do them at 10.00pm tonight. 

Lisa R. 

These are the current gards runs: 

vo ghidra /dev/ttyp2 (v7.1 15) (godzilla/7576 174), start Thu 1 1/3 9:28, 2 licenses 
geert ghidra /dev/tty (v7. 1 1 5) (godzilla/7576 1083), start Thu 1 1/3 17:51 
vo ghidra /dev/tty (v7.1 15) (godzilla/7576 1 142), start Thu 1 1/3 1 8:07, 2 licenses 
torn narcissus /dev/tty (v7.1 15) (godziila/7576 665), start Thu 1 1/3 18:08 
tom marathon /dev/tty (v7.1 15) (godzilla/7576 361), start Thu 1 1/3 18:08 

and this is the chipq: 

ID Target Directory Machine(pid) Who Stat 


1 1671 proteus/gards tomato(27296) tom 5:28 

2 1672 proteus/exlax/elibsrc tomato(27314) tom wait 

3 1687 proteus/compass/Iayouts thoas( 10969) wampler wait 
4 1691 tools/src/twinvia thoas(2]049) wampler wait 

5 1692proteus/gardswarts/protowart thoas(25218) wampler wait 


Okay. 1 was hoping to get a snapshot done so that Dave could start up a DRC 
and Kurt could start up a fracture of the euterpe baseplate. Tvo spotted 
and error in pl_euh which Kurt and Rich have patched. I believe that fix 
has been checked in and released but has not yet shown up in /u/chip. I _think_ 
the stuff in the chipq should handle that. Do I have that right? 

At any rate, I don't think your release should affect being able to create 

a snapshot. I think the DRc/fi-acture shouold be done from the snapshot area. 

I just wanted to let people know that Euterpe baseplate status. 

-hopper 
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From: tbr 

Sent: Thursday, November 03, 1 994 1 1 : 1 8 PM 

To; 'Mark Hofmann' 

Cc: 'Geert Rosseel'; 'Lisa Robinson'; 'Tliomas Laidig'; Vant@boreas'; Tom Vo'; 'Kurt Wampler' 

Subject: Re: proteus release 


Follow Up Flag: Follow up 
Flag Status: Red 


Mark Hofinann wrote (on Thu Nov 3): 

Lisa Robinson writes: 

1 need to do two proteus releases, one in libsrc and one in misc. 
Unless I hear otherwise, Til do them at 10.00pm tonight. 

Lisa R. 

These are the current gards runs: 

vo ghidra /dev/ttyp2 (v7.1 15) (godzilIa/7576 174), start Thu 1 1/3 9:28, 2 licenses 
geert ghidra /dev/tty (v7.1 1 5) (godzilla/7576 1083), start Thu 1 1/3 17:51 
vo ghidra /dev/tty (v7. 1 1 5) (godzilla/7576 1 142), start Thu 1 1/3 1 8:07, 2 licenses 
torn narcissus /dev% (v7.1 15) (godzilla/7576 665), start Thu 1 1/3 18:08 
tom marathon /dev/tty (v7J 15) (godzilla/7576 361), start Thu 1 1/3 1 8:08 

and this is the chipq: 

ID Taiget Directoiy Machine(pid) Who Stat 


1 1671 proteus/gards tomato(27296) tom 5:28 

2 1672 proteus/exlax/elibsrc tomato(27314) tom wait 

3 1687 proteus/compass/layouts thoas( 10969) wampler wait 

4 1691 tools/src/twinvia thoas(21049) wampler wait 

5 1692 proteus/gards warts/protowart thoas(25218) wampler wait 


Okay. I was hoping to get a snapshot done so that Dave could start up a DRC 
and Kurt could start up a fracmre of the euterpe baseplate. Tvo spotted 
and error in pl euh which Kurt and Rich have patched. I believe that fix 
has been checked in and released but has not yet shown up in /u/chip. I _think_ 
the stuff in the chipq should handle that. Do I have that right? 

At any rate, I don't think your release should affect being able to create 

a snapshot. I think the DRc/fracture shouold be done from the snapshot area. 

I just wanted to let people know that Euterpe baseplate status. 

I think after the gardswart builds, we need an update-chip in 
proteus/ged/pl to get the verilog representation regenerated 
from the schematic (which includes the body that came from the 
gards netlist that came from the verilog m proteus/verilog/src/pl). 

Whew! I which this link^e was automatic. 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Kurt Warn pier [wampler@thoas] 
Friday, November 04, 1994 12:05 AM 
'hopper@boreas'; 'tbr@aphrodite' 

'geert@boreas'; 'lisar@rhodan'; 'tom@boreas'; Vant@boreas'; 'vo@boreas' 
Re: proteus release 


hopper wrote: 


Okay, I was hoping to get a snapshot done so that Dave could start up a DRC and Kurt could 
start up a fracture of the euterpe baseplate. Tvo spotted and error in pl_euh which Kurt 
and Rich have patched. I believe that fix has been checked in and released but has not yet 
shown up in /u/chip. I _think_ the stuff in the chipq should handle that. Do I have that 

right? 

At any rate, I don't think your release should affect being able to create a snapshot. I 
think the DRc/ fracture shouold be done from the snapshot area. 
I just wanted to let people know that Euterpe baseplate status, 

tbr replied: 


I think after the gardswart builds, we need an update-chip in proteus /ged/pl to get the 
verilog representation regenerated from the schematic {which includes the body that came 
from the gards netlist that came from the verilog in proteus/verilog/src/pl) . 

wampler replies: 


The release of pl_euh & pl_euh_sofa completed, and the fixed layouts have 
propagated to /u/ chip/proteus/ compass/ layouts . I also just completed 
a ".0" releasebom in proteus/gardswarts -- only the pl_euh gardswart 
rebuilt itself the other two were up-to-date. Everything looks stable 
in wart land. 


- Kurt 
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From: Mark Hofmann [hopper@cy clops] 
Sent: Friday, November 04, 1994 7:12 AM 
To: Tom Laidig' 

Cc: 'tbr@aphrodite'; 'hopper@boreas'; 'geert@boreas'; 'lisar@rhodan'; 'tom@boreas'; 'vant@boreas'; 
Vo@boreas'; •wainpler@thoas' 

Subject: Re: proteus release 

Tom Laidig writes: 
OK, as per later discussions, I did a getbom in 
euterpe-snapshot/euterpe/proteus/compass. This is now complete. Is 
tliere a reason not to start up the getbom in 
euterpe-snapshot/euterpe/proteus now? 

I don't thinlc so. Fire it off... 
-hopper 
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From: Mark Hofmann [hopper@boreas] 
Sent: Friday. November 04, 1994 9:40 AM 
To: 'Brendan Eich' 
Cc: tbr@boreas' 

Subject: Re: Challenge / Irix 5.x Memory addressability question 

Brendan Bich writes: 

Tlie Power Challenge is TFP, or Twin Peaks (or T4?) based. TFP is a fast SGI 
reimplementation of the MIPS R4000 non-FP architecture with new and claimed- 
to-be-better floating point I don't know the prices for these beasts, but 
jsw might know. 

Okay. Thanks for the info. 

-hopper 
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From: tbr 

Sent: Friday, November 04, 1994 12:44 PM 

To: 'Mark Hofmann* 

Cc: 'geert@boreas'; 'lisar@rhodan'; 'tom@boreas'; 'vant@boreas'; 'vo@boreas'; 'Kurt Wampler' 

Subject: Re: proteus release 
Follow Up Flag: Follow up 

Flag Status: Red 


Mark Hofmann wrote (on Fri Nov 4): 

Kurt Wampler writes: 

The release of pl_eiih & pl_euh_sofa completed, and the fixed layouts have 
propagated to /uychip/proteus/compass/layouts. I also just completed 
a ".0" releasebom in proteus/gardswarts -- only the pLeuh gardswart 
rebuilt itself - the other two were up-to-date. Everything looks stable 
in wart land. 

Okay. Good. 

The chipq is empty, as well. 

Let's proceed with the snap shot and then launch DRC and fracture of the 
baseplate from there. 

I ran the update-chip to get the verilog abstraction rebuilt 

Last night I found some inconsistencties in the proteus snapshot under 
the snapshot euteipe (missing stuff in verilog/libsrc). 

I think we need to pull the latest BOM into that version of proteus 
and do the incremental build to be sure we have everything current. 

Comments? 

Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Tim B. Robinson [tbr@aphrodite] 
Friday, November 04, 1994 12:44 PM 
'Mark Hofmann' 

■geert@boreas'; 'lisar@rliodan'; 'tom@boreas'; Vantigboreas'; 'vo@boreas'; 'Kurt Wampler' 
Re: proteus release 


Mark. Hofmann wrote (on Fri Nov 4) : 

Kurt Wampler writes: 

The release of pl_euh & pl_euh_sofa completed, and the fixed layouts have 
propagated to /u/chip/proteus/compass/ layouts , I also just completed 
a ".0" releasebom in proteus /gardswarts -- only the pl_euh gardswart 
rebuilt itself -- the other two were up-to-date. Everything looks stable 
in wart land. 

Okay. Good. 

The chipq is empty, as well. 

Let ' s proceed with the snap shot and then launch DRC and fracture of the 
baseplate from there. 

I ran the update-chip to get the verilog abstraction rebuilt. 

Last night I found some inconsistencties in the proteus snapshot under the snapshot 
euterpe (missing stuff in verilog/libsrc) . 

I think we need to pull the latest BOM into that version of proteus and do the incremental 
build to be sure we have everything current. 


Comments? 


Tim 
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From: 


craig 

Friday, November 04, 1994 12:55 PM 
'cralg@echidna'; 'wayne@echidna' 
'euterpe' 

Re: bring-up meeting of November 2 


Sent: 

To: 

Cc: 


Subject: 


Wayne wrote: 

> Ask Craig if an abort invalidates the byte in transit 

> or the entire packet. (Wayne) 

Craig, I was given an action item to verify a question with you. 
When an Abort is issued, is the byte only invalidated, or is the 
entire packet be invalidated. In addition, is there a specific time 
response for the sending device to respond to the Abort (retransmit) 
before another device grabs the bus, or is it first come first serve 
here? 

Thanks, 

Wayne 

Craig responds : 

An abort, in which the SD line is driven low for 12-22 cycles, 
causes the entire transaction to be ciborted. This is more extensive 
than the choices you gave me (byte in transit or the entire packet) ; 
the entire transaction is aborted, no matter whether the current 
packet is a request or response, [see page TSA 14-Apr-94 page 294.] 

After an abort, the next transaction may begin immediately upon 

seeing SD high for one cycle (which ends the abort) [Page 294] . 

A device which has lost the arbitration of a collision, or has 

suffered the occurrence of a transaction abort, may retry the 

transmission immediately [Page 296] . All other devices must wait 

one additional cycle before transmitting, ensuring that 

all devices which have collided perform their operations before 

another set of devices arbitrate again [Page 296] . It may be noted 

that other devices which were arbitrating for access at the 

same time as the device which initiated the aborted transaction 

get the opportunity to respond at the same time as the 

previous initiator; provided that the contents of the requests 

are the same as the previous transaction, the result of 

the arbitration on the retransmitted transaction 

should be the same as the previous, aborted, transaction. 

The above mechanism might appear to ensure that an transaction 

initator, one having begin a transaction can simply assume that 

it need not worry about another transaction grabbing the bus 

away. However, this is not the case. Firstly, a transaction 

abort may occur before arbitration has been completed on 

the local Cerberus bus, and the initator may lose arbitration 

on the retransmission. The initator must be prepared to 

accept the loss of arbitration, even when the loss implies 

that it must respond as a target of the transaction. 

Secondly, gateways and repeaters may need to apparently 

override the local fairness mechanism to ensure global 

fairness or to avoid system deadlock, and in such cases, 

may begin a retransmission immediately upon the end of 

an abort even though it wasn't among the set of initiators 

of the previous transaction, [see page 307] 

Also, a device which requires a delay after an aborted transaction 
may force the delay bit after the first byte of the immediately 
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following transaction, and may cause the first byte to be 
re- transmitted by aborting the following transaction after 
requesting a suitable delay [page 297] , 

Regards, 
Craig 
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Sent: 

To: 

Cc: 


From: 


Craig Hansen [craig@mnemosyne] 
Friday, Novennber 04, 1994 1:55 PM 
'craig@echidna'; 'wayne@echldna' 
'euterpe@nrinemosyne' 


Subject: 


Re: bring-up nrieeting of November 2 


Wayne wrote: 

> Ask Craig if an abort invalidates the byte in transit 

> or the entire packet. (Wayne) 

Craig/ I was given an action item to verify a qiiestion with you. 
When an Abort is issued, is the byte only invalidated, or is the 
entire packet be invalidated. In addition, is there a specific time 
response for the sending device to respond to the Abort (retransmit) 
before another device grabs the bus, or is it first come first serve 
here? 

Thanks / 

Wayne 

Craig responds : 

An abort, in which the SD line is driven low for 12-22 cycles, 
causes the entire transaction to be aborted. This is more extensive 
than the choices you gave me (byte in transit or the entire packet) ; 
the entire transaction is aborted, no matter whether the current 
packet is a request or response, [see page TSA l4-Apr-94 page 294.] 

After an abort, the next transaction may begin immediately upon 

seeing SD high for one cycle (which ends the abort) [Page 294] . 

A device which has lost the arbitration of a collision, or has 

suffered the occurrence of a transaction abort, may retry the 

transmission immediately [Page 2963 . All other devices must wait 

one additional cycle before transmitting, ensuring that 

all devices which have collided perform their operations before 

another set of devices arbitrate again [Page 296] . It may be noted 

that other devices which were arbitrating for access at the 

same time as the device which initiated the aborted transaction 

get the opportunity to respond at the same time as the 

previous initiator; provided that the contents of the requests 

are the same as the previous transaction, the result of 

the arbitration on the retransmitted transaction 

should be the same as the previous / aborted, transaction. 

The above mechanism might appear to ensure that an transaction 
initator, one having begin a transaction can simply assume that 
it need not worry about another transaction grabbing the bus 
away. However, this is not the case. Firstly, a transaction 
abort may occur before arbitration has been completed on 
the local Cerberus bus, and the initator may lose arbitration 
on the retransmission. The initator must be prepared to 
accept the loss of arbitration, even when the loss implies 
that it must respond as a target of the transaction. 
Secondly, gateways and repeaters may need to apparently 
override the local fairness mechanism to ensure global 
fairness or to avoid system deadlock, and in such cases, 
may begin a retransmission immediately upon the end of 
an abort even though it wasn't among the set of initiators 
of the previous transaction, [see page 307] 

Also, a device which requires a delay after an aborted transaction 
may force the delay bit after the first byte of the immediately 
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following transaction, and may cause the first byte to be 
re -transmitted by aborting the following transaction after 
requesting a suitable delay [page 297] . 

Regards , 
Craig 
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From: Tom Laidig [tom@clio] 

Sent: Friday, November 04, 1994 2:54 PM 

To: Tim B. Robinson' 

Cc: 'liopper@boreas'; 'geert@boreas'; Tisar@rhodan'; 'tom@boreas'; 'vant@boreas'; 'vo@boreas'; 
'wampler@tlioas' 

Subject: Re: proteus release 
Tim B. Robinson writes; 


[Mark Hofmann wrote (on Fri Nov 4): 

I Kurt Wampler writes: 

I The release of pl_euh & pl_euh_sofa completed, and the fixed layouts have 

I propagated to /u/chip/proteus/compass/layouts. I also just completed 

I a ".0" releasebom in proteus/gardswarts ~ only the pl_euh gardswart 

I rebuilt itself ~ the other two were up-to-date. Everything looks stable 

I in wart land. 

1 Okay. Good. 

I The chipq is empty, as well. 

j Let's proceed with the snap shot and then launch DRC and fracture of the 
I baseplate from there. 

jl ran the update-chip to get the verilog abstraction rebuilt. 

[Last night I found some inconsistencties in the proteus snapshot under 
jthe snapshot euterpe (missing stuff in verilog/libsrc). 

jl think we need to pull the latest BOM into that version of proteus 
land do the incremental build to be sure we have everything current. 

OK, as per later discussions, I did a getbom in 
euterpe-snapshot/euterpe/proteus/compass. This is now complete. Is 
there a reason not to start up the getbom in 
euterpe-snapshot/euterpe/proteus now? 


TomL 
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From: Tom Laidig [tom@clio] 

Sent: Friday, November 04, 1 994 3: 1 7 PM 

To: 'Mark Hofmann' 

Cc: tbr@aphrodite'; 'hopper@boreas'; 'geert@boreas'; 'lisar@rhodan'; 'tom@boreas'; 'vant@boreas'; 
Vo@boreas'; 'wampler@thoas' 

Subject: Re: proteus release 

Mark Hofmann writes: 
I 

|Tom Laidig writes: 

I OK, as per later discussions, I did a getbom in 

I euterpe-snapshot/euterpe/proteus/compass. This is now complete. Is 

I there a reason not to start up the getbom in 

I euterpe-snapshot/euterpe/proteus now? 

I 

|I don't think so. Fire it off... 
It's happening now as I type... 

TomL 
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From: Geert Rossee! [geert@ambiorjx] 
Sent: Friday, November CM, 1994 4:49 PM 
To: tbr@ambiorix'; Vanthof@ambiorix* 
Subject: initjnst 

I am conlused about the init__ii]St directive for topt. 

I build apower.tab. local file for cp that contains all instances 
with a init inst directive. I though that topt was going to 
change the power-levels except on the I/O blocks. However, 
topt seems to treat all cells as forced and does not change the 
power-level on any cell. 

All data is in 

/n/ghidra/s3/geert/euterpe/verilog/bsrc/cp 
Geert 
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From; vant [vanthof@hestia] 

Sent: Friday, November 04, 1994 4:52 PM 

To: 'Geert Rosseel' 

Cc: 'tbrigambiorix'; 'vanthof@ambiorix' 

Subject: Re: initjnst 


Geert Rosseel writes: 
> 

> I am confused about the init_inst directive for topt. 
> 

> I build apower . tab . local file for cp that contains all instances with 
>a init_inst directive . I though that topt was going to change the 
>power- levels except on the I/O blocks. However, topt seems to treat all 
>cells as forced and does not change the power-level on any cell. 

> 

> All data is in 

■> 

> /n/ghidra/s3/geert/euterpe/verilog/bsrc/cp 
> 

> Geert 

Within the cp block that is true, but when the cp is included in the top level, topt will 
allow changes to happen because the init_inst in the power . tab . local is not propogated to 
the top level, 

when power optimizing a block, the init_inst and inst directives act identical, but 
init_inst is not propogated to the top level power . tab. local, while inst is. 

Does this help? 
Dave 

Dave Van't Hof vanthof ®microunity . com MicroUnity Systems Engineering, 
Inc . 

"What rolls down stairs, alone or in pairs, rolls over the neighbor's dog? 

What's great for a snack and fits on your back? It's log, log, log I" 
LOG from BLAMMO ! (tm) All kids love Log! #incluce 
<std disclaim. h> 
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From: Tom Laidig [tom@clio] 

Sent: Friday, November 04. 1 994 6:00 PM 

To: Tom Laidig' 

Cc: 'hopper@cyclops'; 'tbr@aphrodite'; 'hopper@boreas'; 'geert@boreas'; 'lisar@rhodan'; 
'tom@boreas'; Vant@boreas'; 'voigboreas'; •wampler@thoas' 

Subject: Re: proteus release 

Tom Laidig writes: 
|Mark Hofmann writes: 
1 1 Tom Laidig writes: 

II OK, as per later discussions, I did a getbom in 

II euterpe-snapshoVeuterpe/proteus/compass. This is now complete. Is 

11 there a reason not to start up the getbom in 

II euterpe-snapshot/euterpe/proteus now? 

III don't think so. Fire it off... 
jit's happening now as I type... 
OK, 'tis done. 

TomL 
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From: 
Sent: 
To: 

Subject: 


lisa 

Friday, November 04, 1994 6:19 PM 
'software-checkins-dlst' 
gnu-tools/sim/terp memory.c 


Update of /p/cvsroot/gnu-tools/sim/terp 

In directory calliope: /N/auspex/root/s6/lisa/src/gnu-tools/sim/terp 

Modified Piles: 
memory . c 

Log Message: 

Implemented the queue for nb-accesses which are serialized (tlh'S/ etc.); they are doled 
out one-at-a-time, f if o- style. 
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Subject: 


Sent: 

To: 

Cc: 


From: 


vant [vanthof@hestia] 

Friday, November 04. 1994 6:26 PM 

'Mark Hofmann'; 'Geert Rosseel'; 'Lisa Robinson'; Tim B. Robinson'; Tom Vo" 
'Dave Van't Hof ; Tliomas Laidig' 
euterpe drc's 


I ' ve started the euterpe drc runs : 

upper drc's on medusa 

lower drc ' s on Cyclops and trex 

I have both processors busy on medusa, so if that machine could be treated as drc only^ 
ie; no chip related functions, the drc's will finish much faster. 

If Cyclops could be limited to only one chip related function so as not to slow down the 
dracula job, that would also help a lot. 

Some conversion stats: 


If we see a 2x improvement {which we should), then the uppers should finish in about 1.5-2 
days and the first phase of the lower should finish in about 3.5-4 days, hopefully less. 

Is it possible to start up an Ivs as well? 


upper drc ' s : 
lower drc ' a : 


90% of the checks were converted to vlsimm 
69% of the checks were converted to vslimm 


Thanks , 
Dave 


Dave Van't Hof vant hof ®microunity . com MicroUnity Systems Engineering, 
Inc . 

"What rolls down stairs, alone or in pairs, rolls over the neighbor's dog? 


What's great for a snack and fits on your back? it's log, log, log! 
LOG from BLAMMO! (tm) All kids love Log I # inc luce 

<std_disclaim.h> 
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From: 
Sent: 
To: 

Subject: 


Buffalo Chip [chip@rhea] 

Friday, November 04, 1994 6:54 PM 

'geert@rhea' 

pager log message 


page from chip to geert : 

Release euterpe/verilog/bsrc/es BOM 65.0 initiated by dickson completed ® Fri Nov 4 
15:51:48 PST 1994 with exit Status 1.. chip 

all ports busy- 
all ports busy- 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
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From: 
Sent: 
To: 

Subject: 


lisa 

Friday, November 04, 1994 7:09 PM 
'software-checkins-dist' 
gnu-tools/sim/terp decode, c 


update of /p/cvsroot/gnu-tools/sim/terp 

In directory calliope: /N/auspex/root/s6/lisa/src/gnu-tools/sira/terp 

Modified Files: 
decode . c 
Log Message: 

For I_BI insns, only set rdest if opcode is blinki (bi ' s were tracking rO as a 
destination) . 
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From: lisa 

Sent: Friday, November 04, 1 994 7:12 PM 

To: 'Derek Iverson' 

Cc: 'gmo' 

Subject: Re: terp errantly commits to reg 0 on a ^bi' 


I just checked- in a fix. (It wasn't actually touching register 0, it was just *saying* 
that it did. ) 

lisa 
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From: B. P. Wong [bpw@frodo] 

Sent: Friday, November 04. 1994 7:31 PM 

To: 'mnemo@frodo' 

Cc: 'bpw@frodo' 

Subject: IMMINENT DECISION: PCI driver 


IMMINENT DECISION: 

We have decided to use the IDT FCT buffer P.N, IDT74FCT16424 5T as the PCI driver. We will 
then use the current euterpe I/O buffer as the mnemo I/O buffer even for the PCI bus. The 
PCI bus will be buffered by the IDT74PCTI64245T. 

Background info: 

The PCI bus according to the PCI electrical specification rev 2.0 is a very hostile 
environment. The 3 most notorious specs for 5V signalling are listed below: 

PCI Rev 2.0 IDT spec 

o AC loh (at Vout s 3.1V) = -142 mA -180 mA 

o AC lol (at Vout = 0.71) = 206 mA 200 mA 

o Overshoot tolerance = IIV for llnS 7V for 20nS 

The IDT part is the only part that comes close to meeting all the nasty PCI specs. 

It will be a major undertaking to meet the AC current specs and the overshoot spec if we 
are to design a PCI compliant buffer on chip, not to mention the large di/dt noise we have 
to content with. A logical solution is to use an external buffer to do the 
3 to 5 Volt level translation and at the same time buffer mnemo from the hostile PCI 
environment . 

Date for Final DECISION is set at Wednesday, Nov 9, 1994 at 8:00am if there is no 
objection to this proposal. 

bpw 
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From: 
Sent: 
To: 

Subject: 


Buffalo Chip [chip@ghiclra] 

Friday, November 04, 1994 8:15 PM 

'geert@ghidra' 

output of euterpe/verilog/bsrc/cp/.ciieckoutrc 


The output from euterpe/verilog/bsrc/cp/ . checkoutrc is 176k, so it is not included in this 
mail message. Instead, check the file 

/n/trap/chiplog/geert . ghidra . 3569 . euterpe-verilog-bsrc-cp 

(which is accessible from all machines) . This file will disappear in about 5 days. 
By the way, the exit status returned by .checkoutrc was 0. 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Tom Vo [vo@merope] 

Friday, November 04. 1994 8:26 PM 

'Lisa Robinson' 

'Mark Hofmann'; Tim B. Robinson'; 'Geert Rosseel'; 'Dave Van't Hof ; 'Kurt Wampler' 
protection in s41 


My rebuild of euterpe in s4l failed because of permission problem , 

cp : /n/auspex/ s41 /euterpe- snapshot /euterpe/compass/baseplate/knobmap, ly : 
Not owner 

cp: 

/n/auspex/s41/euterpe-snapshot/euterpe/compass/baseplate/knobmaptext . ly: 

Not owner 

cp: 

/n/auspex/s4l/euterpe- snapshot /euterpe/compass/baseplate/knobstraps.ly: 

Not owner 

cp; 

/n/auspex/s4l/euterpe-snapshot/euterpe/compass/baseplate/knobstraps_drive. 

ly: Not owner 

cp: 

/ n/auspex/ s41 /euterpe -snapshot /euterpe/ compass /baseplate/knobs traps straps 
. ly : Not owner 

cp: /n/auspex/s4l/euterpe-snapshot/euterpe/compass/baseplate/clockbias . ly : 

Not owner 

cp: 

/n/auspex/s41/euterpe-snapshot/euterpe/compass/ba5eplate/cgclockbias . ly : 
Not owner 

gmake [1] : *** [cgclockbias . ly] Error 1 
gmake[l]: Leaving directory 
/N/ auspex / roo t / s4 1 / eut e rpe - s napshot / eut er pe / clockbias* 

But when l check the files attributes , it ' s group writable . 


???? 


tvo 
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Subject: 


From: 


Sent: 

To: 

Cc: 


Lisa Robinson [lisar@nosferatu] 
Friday, November 04, 1994 8:32 PIVI 
'Tom Vo'; 'doi@nosferatu': 'tom@nosferatu' 

•Geert Rosseel'; 'Mark Hofmann'; Tim B. Robinson'; 'Dave Van't Hof; 'Kurt Wampler' 
protection in 841 


Tom Vo wrote (on Fri Nov 4) : 


My rebuild of euterpe In s41 failed because of permission problem . 

cp: 

/n/auspex/s41/euterpe-snapshot/euterpe/compass/baseplate/knobmap . ly: Not owner 
cp: 

/ n / auspex/ s 4 1 / eut erpe - snap sho t / eu t erpe / c ompa s s /basepl a t e / knobmap t ext . ly : 
Not owner 

cp: 

/n/auspex/s4l/euterpe-snapshot/euterpe/compass/baseplate/knobstraps . ly; 
Not owner 
cp: 

/n/auspex/s41/euterpe- snapshot /euterpe/compass/baseplate/knobstraps_drive . 

ly: Not owner 
cp: 

/n/auspex/s41/euterpe- snapshot /euterpe/compass/baseplate/knobstraps_straps 
.ly: Not owner 
cp: 

/n/auspex/s41/euterpe-snapshot/euterpe/compass/baseplate/clockbias . ly : Not owner 
cp: 

/n/auspex/ s41/euterpe- snapshot /euterpe/corapass/baseplate/cgclockbias. ly: 
Not owner 

gmake [1] : *** [cgclockbias . ly] Error 1 
gmake[l]: Leaving directory 
"/N/auspex/root/s41/euterpe-snapshot/euterpe/clockbias ' 

But when I check the files attributes , it ' s group writsdale , 

???? 
tvo 

I'm confused too. 
what group are you? 


lisar©rhodan /s3/euterpe/verilog/bsrc 463 % Is -Is /n/auspex/s41/euterpe- 
snapshot /eut erpe/ compass /baseplate/knobmap . ly 

4 -rw-rw-r-- 1 lisar 3437 Nov 4 17:03 

/n/auspex/s41/euterpe-snapshot/euterpe/compass/baseplate/knobmap . ly 
lisar®rhodan /s3/euterpe/verilog/bsrc 464 % Is -Isd / n/auspex /s41/ eut erpe - 
snapshot /euterpe/compass/baseplate 

34 drwxrwxr-x 2 lisar 34304 Nov 4 17:28 

/n/auspex/s41/euterpe-snapshot/euterpe/compass/baseplate 

lisar@rhodan /s3/euterpe/verilog/bsrc 465 % Is -Isdd /n/auspex/ s41/ euterpe - 
snapshot /euterpe/ compass/baseplate 

34 drwxrwxr-x 2 lisar 34304 Nov 4 17:28 

/n/auspex/ s41/euterpe- snapshot /euterpe/compass/baseplate 

lisar@rhodan /s3/euterpe/verilog/bsrc 466 % Is -Isg /n/auspex/s4l/euterpe- 
snapshot /euterpe/compass/baseplate 

lisarOrhodan /s3/euterpe/verilog/bsrc 467 % Is -Isgd /n/auspex/s41/euterpe- 
snapshot / euterpe/compass/baseplate 

34 drwxrwxr-x 2 lisar cad 343 04 Nov 4 17:28 
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/ n/ auspex/ s 4 1 / euterpe - snapshot / eut e rpe / c ompas s / ba Sep la t e 
Can any one help? 
Lisa R. 


Exhibit C8 


Page 141 of 598 


From: vant [vanthof@hestia] 

Sent: Friday, November 04, 1994 8:34 PM 

To: 'Lisa Robinson' 

Cc: Vo@merope'; 'cloi@nosferatu'; 'tom@nosferatu'; 'geert@merope'; 'hopper@merope'; 

'tbr@nnerope'; 'vanthof@nnerope'; 'wampler@merope' 
Subject: Re: protection in s41 


Lisa Robinson writes: 

> But when I check the files attributes , it ' s group writable . 
> 

> ???? 

> tvo 
> 

>I'm confused too. 
> 

>What group are you? 

Tom is in the CAD group, so it should be writable by him. 


>lisar@rhodan /s3/euterpe/verilog/bsrc 463 % Is -Is 

/n/auspex/ s4 1/euterpe- snapshot/euterpe/compass/baseplate/knobmap . ly 

> 4 -rw-rw-r-- 1 lisar 3437 Nov 4 17:03 

/n/auspex/s4 1/euterpe- snapshot/euterpe/compass/baseplate/knobmap . ly 
>lisar@rhodan /s3/euterpe/verilog/bsrc 4 64 % Is -Isd 
/n/auspex/ s4 1/euterpe -snapshot/euterpe/ compass/baseplate 

> 34 drwxrwxr-x 2 lisar 343 04 Nov 4 17:28 
/n/auspex/ s41/euterpe- snapshot /euterpe/compass/baseplate 
>lisar@rhodan /s3/euterpe/verilog/bsrc 465 % Is -Isdd 
/n/auspex/ s4 1/euterpe -snapshot /euterpe/compass/baseplate 

> 34 drwxrwxr-x 2 lisar 343 04 Nov 4 17:28 
/n/auspex/s4 1/euterpe -snapshot/euterpe /compass /baseplate 
>lisar®rhodan /s3/euterpe/verilog/bsrc 466 % Is -Isg 
/n/auspex/ s4 1/euterpe -snapshot /euterpe/compass/baseplate 
>^C 

>lisar@rhodan /s3/euterpe/verilog/bsrc 467 % Is -Isgd 
/n/auspex/s4 1/euterpe- snapshot /euterpe/compass/baseplate 

> 34 drwxrwxr-x 2 lisar cad 34304 Nov 4 17:28 
/n/auspex/s41/euterpe-snapshot/euterpe/compass/baseplate 

> 

>Can any one help? 
> 

>LIsa R. 


I managed to cd over there and create a file with no problems. 

Tom, were you doing this as chip? Chip is not in the CAD group that I can tell. 
Dave 


Dave Van't Hof vanthof ©microunity . com MicroUnity Systems Engineering, 

Inc . 

"What rolls down stairs, alone or in pairs, rolls over the neighbor's dog? 

What's great for a snack and fits on your back? It's log, log, log!" 
LOG from BLAMMO! (tm) All kids love Log! #incluce 
<std disclaim. h> 
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From: Tom Vo [vo@merope] 

Sent: Friday, November 04, 1994 8:36 PM 

To: Vanf 

Cc: 'lisar@nosferatu'; 'doi@nosferatu'; 'tom@nosferatu'; 'geert@merope'; 'hopper@merope'; 

•tbr@merope'; Vanthof@merope'; 'wampler@merope' 
Subject: Re: protection in s41 


>I managed to cd over there and create a file with no problems. 

> 

>Tom, were you doing this as chip? Chip is not in the CAD group that I 

can 

>tell. 

I was doing this as vo . The build ran just fine elsewhere rebuilding baseplate and gards 
model . Log file is in /n/auspex/s41/euterpe-snapshot/euterpe/makerrs . vo . 

tvo 
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From: Tom Laidig [tom@clio] 

Sent: Friday, November 04, 1994 8:40 PM 

To: 'Lisa Robinson' 

Cc: 'vo@merope'; 'doi@nosferatu'; 'tom@nosferatu'; 'geert@merope'; ' hopper® merope'; 

'tbr@merQpe'; •vanthof@merope'; 'wampler@merope' 
Subject: Re: protection in s41 


Lisa Robinson writes: 

I 

I Tom Vo wrote (on Fri Nov 4) : 


j My rebuild of euterpe in s41 failed because of permission problem . 

I 

I cp: 

/n/auspex/ s4 1/euterpe 

I cp: 

/n/auspex/s41 /euterpe 
Not owner 
I cp: 

/n/auspex/ s4 1/ euterpe 

Not owner 

I cp: 

/n/auspex /s4l/ euterpe 
ly: Not owner 

I cp: 

/n/auspex/ s4 1/euterpe 
. ly : Not owner 
I cp: 

/n/auspex / s 4 1 / eut erpe 
I cp: 

/n/auspex/ s4 1/euterpe 
Not owner 

i graake [1] ; *** [cgclockbias . ly] Error 1 
I graake [11 ; Leaving directory 

"/N/auspex/root/s4 1/euterpe- snapshot /euterpe/clockbias ' 
I 

I But when I check the files attributes , it's group writable . 
I ???? 

I tvo 

I I'm confused too. 
I What group are you? 


lisarSrhodan /s3/euterpe/verilog/bsrc 463 % Is -Is 

'n/auspex/s4l/euterpe-snapshot/euterpe/compass/baseplate/knobmap. ly 

4 -rw-rw-r-- 1 lisar 3437 Nov 4 17:03 

' n/ auspex/ s 4 1 / eut erpe - snap sho t / eut e rpe / c ompa s s / ba s ep 1 a t e / knobmap . ly 
lisar@rhodan /s3 /euterpe/ verilog/bsrc 464 % Is -Isd 
'n/auspex/s4l/euterpe-snapshot/euterpe/coTnpass/baseplate 

34 drwxrwxr-x 2 lisar 34304 Nov 4 17:28 

'n/auspex/s41/euterpe-snapshot/euterpe/compass/baseplate 
lisarOrhodan /s3/euterpe/verilog/bsrc 465 % Is -Isdd 
'n/auspex/s4 1/euterpe- snapshot /euterpe/compass/baseplate 

34 drwxrwxr-x 2 lisar 34304 Nov 4 17:28 

'n/auspex/ s4l/euterpe-snapshot/euterpe/compass/baseplate 
lisar@rhodan /s3/euterpe/verilog/bsrc 466 % Is -Isg 
n/auspex/ s41/euterpe- snapshot /euterpe/compass/baseplate 


- snapshot /euterpe/compass/baseplate/lmobmap. ly: Not owner 
- snapshot /euterpe/compass/baseplate/knobmaptext . ly : 

-snapshot /euterpe/ compass/baseplate/knobstraps . ly : 

- snap sho t / eut erpe / compa ss /baseplate /knob St rap s_drive . 

- snapshot / eut erpe / compa s s /ba s epl at e / knob s t rap s_s t rap s 

- snapshot /euterpe/compass/baseplate/clockbias. ly: Not owner 
- snapshot/euterpe/corapass/baseplate/cgclockbias . ly : 
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I lisarOrhodan /s3/euterpe/verilog/bsrc 467 % Is -Isgd 

/n/auspex/s41/euterpe- snapshot /euterpe/compass/baseplate 

I 34 drwxrwxr-x 2 lisar cad 3 43 04 Nov 4 17:28 

/n/auspex/s41/euterpe-snapshot/euterpe/compass/baseplate 

I 

Note from the dates above that the actual copying worked. Is this perchance another 
example of the infamous ^cp -p'? You've all heard me belly-ache about this before -- 
well, here's yet another reason not to do this unless it's strictly necessary: when you 
do a "cp -p' to an existing file, the actual copying succeeds if you have write permission 
on the file, but then the backdating fails unless you really are the owner of the file. 

Solutions : 

don't use cp -p 

do an rm -f of the old file before copying 


Tom L 
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From: tbr 

Sent: Saturday, November 05, 1 994 1 :44 AM 

To: Tom Laidig' 

Cc: 'geert@boreas'; 'hopper@boreas'; 'lisar^rhodan'; 'tom@boreas'; Vant@boreas'; 

'vo@boreas'; 'wampler@thoas' 

Subject: Re: proteus release 

Follow Up Flag: Follow up 

Flag Status: Red 


Tom Laidig wrote (on Fri Nov 4): 
Tim B. Robinson writes: 


[Mark Hofmann wrote (on Fri Nov 4): 

I Kurt Wampler writes: 

I The release of pl euh & pl_euh_sofa completed, and the fixed layouts have 

I propagated to /u/chip/proteus/ compass/1 ay outs . I also j ust compl eted 

I a ".0" releasebom in proteus/gardswarts ~ only the pl_euh gardswart 

I rebuilt itself - the other two were up-to-date. Everything looks stable 

I in wart land. 

I Okay. Good. 

I The chipq is empty, as well. 

I Let's proceed with the snap shot and then launch DRC and fracture of the 
) baseplate from there. 

|I ran the update-chip to get the verilog abstraction rebuilt. 

ILast night I found some inconsistencties in the proteus snapshot under 
jthe snapshot euterpe (missing stuff in verilog/libsrc). 

jl think we need to pull the latest BOM into that version of proteus 
land do the mcremental build to be sure we have everything current. 

OK, as per later discussions, I did a getbom in 
euterpe-snapshot/euterpe/proteus/compass. This is now complete. Is 
there a reason not to start up the getbom in 
euterpe-snapshot/euterpe/proteus now? 

No reason. However, given Tve been offline so long, did this get 
done. A cvs status right now says it's out of date again: 


File: BOM Status: Needs Checkout 

Version: 5.52 1 Fri Nov 4 1 2; 1 6:34 1 994 
RCS Version: 5.527 /p/cvsroot/proteus/BOM,v 
Sticky Tag: (none) 
Sticky Date: (none) 
SticlQ' Options: (none) 
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From: tbr 

Sent: Saturday, November 05, 1994 1:58 AM 

To: 'vant' 

Cc: 'Geert Rosseel'; 'Mark Hofmann'; 'Lisa Robinson'; 'Thomas Laidig'; 'Dave Van't Hof ; 'Tom 

Vo' 

Subject: euterpe drc's 

Follow Up Flag: Follow up 
Flag Status: Red 


vant wrote (on Fri Nov 4): 


I've started the euterpe drc runs: 

upper drc's on medusa 

lower drc's on cyclops and trex 

I have both processors busy on medusa, so if that machine could be treated as 
drc only, ie; no chip related functions, the drc's will finish much faster. 
If cyclops could be limited to only one chip related function so as not 
to slow down the dracula job, that would also help a lot. 

That should be the default unless someone explicitly promotes a second 
job with -noconflict. 

Some conversion stats: 

upper drc's: 90% of the checks were converted to visimm 
lower drc's: 69% of the checks were converted to vslimm 

If we see a 2x improvement (which we should), then the uppers should finish 
in about 1.5-2 days and the first phase of the lower should finish in 
about 3.5-4 days, hopefully less. 

Is it possible to start up an Ivs as well? 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Tim B. Robinson [tbr@aphrodite] 
Saturday, November 05, 1994 1:68 AM 
Vant' 

'Geert Rosseel'; 'Mark Hofmann'; 'Lisa Robinson'; 'Tiiomas Laidig'; 'Dave Van't Hof; Tom Vo' 
euterpe drc's 


vant wrote (on Fri Nov 4) : 


I've started the euterpe drc runs: 


upper drc's on medusa 

lower drc ' s on cyclops and trex 


I have both processors busy on medusa, so if that machine could be treated as 
drc only, ie; no chip related functions, the drc's will finish much faster. 
If cyclops could be limited to only one chip related function so as not 
to slow down the dracula job, that would also help a lot. 

That should be the default unless someone explicitly promotes a second job with - 
noconf lict . 

Some conversion stats: 


If we see a 2x improvement (which we should) , then the uppers should finish 
in about 1,5-2 days and the first phase of the lower should finish in 
about 3.5-4 days, hopefully less. 

Is it possible to start up an Ivs as well? 


upper drc ' s : 
lower drc ' s : 


90% of the checks were converted to vlsirara 
69% of the checks were converted to vslimm 
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From: Tim B, Robinson [tbr@aphroclite] 

Sent: Saturday, November 05, 1 994 2:04 AM 

To: 'B. P. Wong' 

Cc: 'bpw@frodo'; 'mnemo@frodo' 

Subject: IMMINENT DECISION: PCI driver 


B. P. Wong wrote (on Fri Nov 4) : 
IMMINENT DECISION: 

We have decided to use the IDT FCT buffer P.N. IDT74FCT164245T as 
the PCI driver. We will then use the current euterpe I/O buffer 
as the mnemo I/O buffer even for the PCI bus. The PCI bus will 
be buffered by the IDT74FCT164245T. 

Background info: 

The PCI bus according to the PCI electrical specification rev 2.0 is 
a very hostile environment. The 3 most notorious specs for 5V 
signalling are listed below: 

PCI Rev 2.0 IDT spec 

o AC loh (at Vout -3.1V) - -142 raA -180 mA 

O AC lOl (at Vout = 0.71) = 206 mA 200 mA 

o Overshoot tolerance = IIV for llnS 7V for 2 0nS 

The IDT part is the only part that comes close to meeting all the 
nasty PCI specs. 

It will be a major undertaking to meet the AC current specs and 
the overshoot spec if we are to design a PCI compliant buffer 
on chip, not to mention the large di/dt noise we have to content 
with. A logical solution is to use an external buffer to do the 
3 to 5 Volt level translation and at the same time buffer mnemo 
from the hostile PCI environment. 

Date for Final DECISION is set at Wednesday, Nov 9, 1994 at 8:00am 
if there is no objection to this proposal. 

How many of these components will be required? I assume we may need several to handle 
control signals that need to be bi-directional with independent controls. 

Tim 
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From: Tim B. Robinson [tbr@aphrodite] 

Sent: Saturday, November 05, 1994 2:19 AM 

To: 'Kurt Wampler' 

Cc: 'geert@boreas'; 'hopper@boreas'; 'lisar@rhodan'; 'tom@boreas'; 'tom@clio'; 'vant@boreas'; 

Vo@boreas' 
Subject: Re: proteus release 


Kurt Wampler wrote (on Fri Nov 4) : 
Tim writes: 


>No reason. However, given I've been offline so long, did this get 
>done. A CVS status right now says it's out of date again: 


> 

>Pile: BOM 

Status : 

Needs Checkout 

> 

> Version: 

5.521 

Fri Nov 4 12:16:34 1994 

> RCS Version: 

5.527 

/p/cvsroot/proteus/BOM, V 

> Sticky Tag: 

(none) 


> Sticky Date: 

(none) 


> Sticky Options: 

(none) 



A CVS log on proteus/BOM indicates that all changes since 5.521 have 
been updates to the "mb" block, with the exception of the single "-" 

that 

I just added to the clockbias Makefile . rules. If "mb" isn't used in 
Euterpe, (is it a Mnemo block?) then there should be no need for another 
getbom, I think. 

rab is indeed mnemo only. 

Tim 
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Sent: 


To: 
Cc: 

Subject: 


From: 


tbr 

Saturday, November 05, 1994 2:27 AM 
"torn' 


'geert'; 'hopper' 
permisions problem 


Follow Up Flag: Follow up 
Flag Status: Red 

1 Just tried to fire off a make of the snapshot proteus following the 
getbom. It died immediately because of a permission problem trying to 
update ged/mb/mb.lib. I restarted it as chip and it has got past 
there. Is everything in that tree owned by chip? We have the euterpe 
snapshot set up to be group writeable by cad so people can work there 
without having to su to chip. Since we don't expect too frequent 
changes to proteus it should be no problem having to su, so long as 
everything is consistently owned by chip. 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Tim B. Robinson [tbr@aphrodite] 
Saturday, November 05, 1994 2:27 AM 
'tom@aphrodite' 

'geert@aphrodite'; 'hopper@aphrodite' 
permisions problem 


I just tried to fire off a make of the snapshot proteus following the getbom. It died 
immediately because of a permission problem trying to update ged/mb/mb. lib. I restarted 
it as chip and it has got past there. Is everything in that tree owned by chip? We have 
the euterpe snapshot set up to be group writeable by cad so people can work there without 
having to su to chip. Since we don't es^ect too frequent changes to proteus it should be 
no problem having to su, so long as everything is consistently owned by chip. 


Tim 
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From: Tim B. Robinson [tbr@aphroclite] 

Sent: Saturday, November 05, 1994 11 :05 AM 

To: 'brianl@aphrodlte' 

Cc: 'hopper@aphrodjte'; 'geert@aphrodite'; 'lisar@aphrodite' 

Subject: snapshot problem 


After torn updated the BOM in the (s23) snapshot proteus, I started a top level make to 
bring everything up to date. It decided it had to remake leaf gen becasue of a change 
which seens only to affect hr cells. As a result it had to re-run timing for those cells. 

I noticed the following in the log output; 


Id. so: warning: /usr/lib/libc . so. 1 . 6 
Id. so: warning: /usr/lib/libc . so. 1 . 6 
Id. SO: warning: /usr/lib/libc . so. 1 . 6 

1.4 real 0.0 user 

/bin/nawk: can't open mlmuxSdf 2s.TOtO 

source line number 30 
/bin/nawk: can't open mlmuxSdf 2s .mtO 

source line number 17 
/bin/nawk: can't open mlmuxSdf 2s .ratO 

source line number 17 
/bin/nawk: can't open mlmuxSdf 2s .ititO 

source line number 17 

mv: mlmuxSdf 2 s.mtO: Cannot access: No such file or directory .. /tools/ simulate- time error: 
mlmuxSdf 2s. scr failed 

.. /tools/simulate- time : moving mlmuxSdf 2s . tira to mlmuxSdf 2s .tim. bad 
and many similar reports . 

Then a little later: 

Making mltime/ralraux4df 6s . tim 
deal: end merope stdout 

deal: begin merope stderr (child 3274, cmd 119, exit 0) ... 

Id. so: warning: /usr/lib/libc . so . 1 . 6 has older revision than expected 8 

Id. so: warning: /usr/lib/libc . so . 1 . 6 has older revision than e^qpected 8 

rewind: [28] No space left on device 

logical unit 1, named ' /tmp/tmp.7_21811' 

Command terminated abnormally. 

84.2 real 63.5 user S.8 sys 

Here's another example: 

Id. so: warning: /usr/lib/libc . so. 1 . 6 . 1 has older revision than expected 8 

1 , 4 real 0 . 0 user 0 . 1 sys 

/bin/nawk: can't open mlmuxen7dhl2s .mtO 

source line number 30 
/bin/nawk: can't open mlmuxen7dhl2s .mtO 

source line number 17 
/bin/nawk: can't open mlmuxen7dhl2s .mtO 

source line number 17 
/bin/nawk: can't open mlmuxen7dhl2s .ratO 

source line number 17 

mv: mlmuxen7dhl2s .mtO : Cannot access: No such file or directory .. /tools/simulate- time 
error: mlmiixen7dhl2s . scr failed 

. . /tools/siraulate-time : moving mlmuxen7dhl2s . tim to mlmuxen7dhl2s . tim.bad 
deal: end mercury stderr (child 12089) 

Now, none of these seem to have stopped the make. What's going wrong here? is this the 
reason we always seem to have a few bad timing numbers lying around? 


. 1 has older revision than expected 8 
.1 has older revision than expected 8 
.1 has older revision than expected 8 
0 . 1 sys 
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The full log is to be found in 

/n/auspex/ s4 1/euterpe - snapshot/euterpe/proteus/makerrs 
Tim 
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From: Tom Vo [vo@merope] 

Sent: Saturday, November 05, 1994 12:42 PM 

To: 'Mark Hofmann'; 'Dave Van't Hof ; Thomas Laldig'; 'Kurt Wampler'; 'Lisa Robinson'; Tim B. 

Robinson'; 'Geert Rosseel' 
Subject: proteus snapshot stale 


Where are we getting the snapshot proteus these days ? 
We're still having problem with the gtlb . 

The one that euterpe snapshot references looks stale : 

-rwxr-xr-x 1 chip 3560421 Nov 4 10:36 

/n/auspex/s2 3 /euterpe -proteus - cp/proteus/ compass/layouts/gt lb . ly 
-rw-rw-r-- 1 chip 139543 Sep 23 21:12 

/n/auspex/ s2 3 / euterpe -proteus- cp/proteus/ compass/dcell /gtlb . ly 

-rwxr-xr-x 1 chip 3560421 Oct 31 15:31 

/u/chip/proteus/compass/layouts/gtlb . ly 
-rw-r--r-- 1 chip 139944 Nov 3 12:42 

/ u / chip /pro teus / compa s s / dee 1 1 / g t lb . ly 

Either the rebuild in the snapshot proteus did not take , or we did not copy all the files 
we need . 

I'm out for the morning . I'll check back in the afternoon . 
tvo 
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From: Geert Rosseel [geert@ambiorix] 
Sent: Saturday, November 05, 1 994 1 :03 PM 
To: 'tbr@ambiorix' 
Subject: euterpe snapshot 


Hi Tim, 

I am not sure what needs to be dpne at the topelevel in the snapshot. 
Please go ahaed and update whatever you think needs it. 

P.S. : Did mouss comer you already with his revived version of 
the XDB for euterpe U ? It is interesting for the datapath 
implementation, but control will be though. 

Geert 
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Subject: 


To: 


Sent: 


From: 


tbr 

Saturday, November 05, 1994 1:24 PM 
'Geert Rosseel' 
euterpe snapshot 


Follow Up Flag: Follow up 
Flag Status: Red 

Geert Rosseel wrote (on Sat Nov 5): 
Hi Tim, 

1 am not sure what needs to be dpne at the topelevel in the snapshot. 
Please go ahaed and update whatever you think needs it. 

P.S. : Did mouss comer you already with his revived version of 
the XDB for euterpe II ? It is interesting for the datapath 
implementation, but control will be though. 

I spent almost the whole day in a re-ed session. Best not discussed 
in email . . . 


Tim 
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From: 
Sent: 
To: 

Subject: 


Tim B. Robinson [tbr@aplirodite] 
Saturday, November 05, 1994 1:24 PM 
'Geert Rosseel' 
euterpe snapsliot 


Geert Rosseel wrote (on Sat Nov 5) : 
Hi Tim, 

I am not sure what needs to be dpne at the tope level in the snapshot. 
Please go ahaed and update whatever you think needs it . 

P.S. : Did mouss corner you already with his revived version of 
the XDB for euterpe II ? It is interesting for the datapath 
implementation, but control will be though. 

I spent almost the whole day in a re-ed session. Best not discussed in email . 

Tim 
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From: Geert Rosseel [geert@ambiorjx] 
Sent: Saturday, November 05, 1994 5:39 PM 
To: 'wampler@ambiorix' 
Cc: 'hopper@ambiorix'; 'tbr@ambiorix' 
Subject: Help on euterpe ? 


Hi Kurt, 

Do you have any free cycles to help on top-level Euterpe routing ? 
Currently, a lot of people are helping out on sub-block placement & routing 
and I am working on the toplevel place and route. I could use help there 
and I'de like to split the task in two where one person works mostly on 
placement and another takes on the routing task. 

Since you are much more familiar with the routing strategies and different 
parameters, I thought I could work further on the placement and you could help 
on routing. 

Thank's 
Geert 
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From: Tom Vo [vo@merope] 

Sent: Saturday, November 05, 1994 5:49 PM 

To: Tim B. Robinson' 

Cc: 'geert@merope'; 'hopper@merope'; 'lisar@merope'; 'tom@merope'; Vanthof@merope'; 

'wampler@merope' 
Subject: Re: proteus snapshot stale 


Tim B. Robinson wrote 


>Tom Vo wrote (on Sat Nov 5) i 

> 
> 

> Where are we getting the snapshot proteus these days ? 

> We're still having problem with the gtlb . 

> 

> The one that euterpe snapshot references looks stale : 

> 

> -rwxr-xr-x l chip 3560421 Nov 4 10:36 
/n/auspex/s2 3 /euterpe-proteus-cp/proteus/ compass/ layout s/gt lb, ly 

> -rw-rw-r-- 1 chip 139543 Sep 23 21:12 
/n/auspex/s23/euterpe-proteus-cp/proteus/corapass/dcell/gtlb. ly 
> 

> -rwxr-xr-x 1 chip 3560421 Oct 31 15:31 
/u/ chip/prot eus / compas s / layout s /gt lb . ly 

> -rw-r--r-- 1 chip 139944 Nov 3 12:42 
/u/ chip/prot eus /compas 5 /dcell /gtlb . ly 

> 
> 

>I'm somewhat confused here. The euterpe snapshot is referencing the 
>snapshot proteus on s23 . According to you're Is the layout in the 
>snapshot looks newer than the one in /u/chip, but cmp thinks they are 
>identical. I assume this is because the date in the snapshot reflects 
>when the getbom ws done by tom yesterday. As for the dcell, it may 
>well not have been remade yet becasue the make has not got that far. 
>Are we actually dependent on the dcell at this stage? 
> 

>Tim 


We are . The dcell for the custom block is really the real layout after it's been 
processed by vlsimm to remove details immaterial to the baseplate build and GARDS model 
generation . 

tvo 
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Sent: 

To: 

Cc: 


Subject: 


From: 


Kurt Wampler [wannpler@thoas] 
Saturday, November 05, 1994 5:56 PM 
'geert@ambiorix' 

'hopper@ambtorix'; 'tbr@ambiorjx' 
Re: Help on euterpe ? 


Geert writes : 


> Do you have any free cycles to help on top-level Euterpe routing ? 
>Currently, a lot of people are helping out on sub-block placement & 
routing 

>and I am working on the toplevel place and route. I could use help 
>there and I ' de like to split the task in two where one person works 
>mostly on placement and another takes on the routing task. 
> 

> Since you are much more familiar with the routing strategies and 
different 

>parameters, I thought I could work further on the placement and you 

>could 

help 

>on routing. 

Yes, I can help. At the moment I'm trying to fix an obstruction 
abstraction inaccuracy that Brian has exposed, but the rest of my "to do" 
list can timeshare with routing work. Of course, if I have problems 
with a route, it may be necessary to adjust the placement sometimes... 

When you have the time, give me a few more of the details and I'll get 


started. 


- Kurt 
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From: Mark Hofmann [hopper@boreas] 
Sent: Saturday, November 05, 1 994 6: 1 6 PM 
To: Tom Vo' 

Cc: Vanti^boreas'; 'tbr@boreas'; 'geert@boreas'; 'lisar@boreas'; 'tom@boreas'; 'wampler@boreas' 
Subject: Re: Top level Makefile 

Tom Vo writes: 
Tm still waiting for the snapshot proteus to get updated . 
When thaf s done , I'll start the euterpe rebuild . 
When thaf s done , you can launch your DRC and fracture . 

Okay, thanks. 

I think I understand the order of events now. 
-hopper 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Tim B. Robinson [tbr@gamorra] 
Saturday, November 05, 1994 7:23 PM 
'Tom Vo' 

'geert@boreas'; 'Mark Hofmann'; 'ljsar@boreas'; 'tom@boreas'; 'vant@boreas'; 

'wampler@boreas' 

Re: Top level Makefile 


Tom Vo wrote (on Sat Nov 5) : 

Mark Hof tnann wrote .... 
> 

>Tom Vo writes: 

> Mark Hofmann wrote .... 

> >I guess none of these things should affect the DRcs or fracture 
runs. 

> >Is this correct? 

> > 

> >- hopper 
> 

> Quite the contrary . The baseplate build referenced data in the 
proteus 

> tree . 

> If there 're inconsistency there , we'll get garbarge for a 

baseplate . 
> 

> The drc jobs that vant started yesterday , and the 2 baseplate 

rebuilds 

> I made should be discarded . For some reason , I thought the 
proteus 

> snapshot was OK . 


>Okay. It turns out the DRCs died anyway. What is the current status? 
Can the 

>DRCs and fracture runs be restarted yet? 
> 

>- thanks, 
> hopper 


I'm still waiting for the snapshot proteus to get updated . 

When that's done , I'll start the euterpe rebuild . 

When that ' s done , you can launch your DRC and fracture . 

According to brianl, the timing run decided to run everything, so if the 40hr number I've 
heard is correct it wont be through that till sometime tomorrow. 


> 


> 


tvo 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Tim B. Robinson [tbr@gamorra] 
Saturday, November 05, 1994 7:29 PM 
'Tom Vo' 

'geert@boreas'; 'Mark Hofmann'; Tisar@boreas'; 'tom@boreas'; 'vant@boreas'; 

'wampler@boreas' 

Re: Top level Makefile 


Tom Vo wrote (on Sat Nov 5) : 


I'm still waiting for the snapshot proteus to get updated . 

When that's done , I'll start the euterpe rebuild . 

When that's done , you can launch your DRC and fracture . 

The first make just completed {exit 1) , This was expected because of the disk full and 
license problems. Brianl has cleaned up the bogus timing files that wer created and I 
have restarted the make . 

Hopefully only about 10% of them should need running on this pass. 
I'll page if I get it to complete successfully. 


Tim 
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From: Geert Rosseel [geert@ghjclraj 

Sent: Saturday, November 05, 1994 7:48 PM 

To: 'tbr@ghidra' 

Subject: euterpe/verilog/bsrc/pimlib. pi 

Hi Tim, 

euterpe/verilog/bsrc/pimlib.pl contains this : 

/^\s*(\S+)\s+(\S+)\s+(\S+)\s*(.*)/ && do { 
printf ("%s%s\t %g\t %g\t %s\n", 

$inst, $1, $2 + Sbaserow, $3 + $basecol, 

(($4 && (substr($4,0,l) ne "#"))? $inst.$4 : $4)); 

in the shifltpim_v subroutine 

Thi sdoes not work because of the $inst.$4 : $4 

Usually, in the pirn files that I see, $4 is someting like <1934 and is an 
alignment mark for pimpif. Adding the $inst does not work . 

Do you remember whay iJiat was added. Are there cases where this is necessary 
but I haven't seen yet. 


Geert 
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From: 


tbr 


Subject: 


Sent: 

To: 

Cc: 


Saturday, November 05, 1994 8:23 PM 

'Geert Rosseel' 

'hopper* 

euterpe/verilog/bsrc/pimlib. pi 


Follow Up Flag: Follow up 
Flag Status: Red 

Geert Rosseel wrote (on Sat Nov 5): 
Hi Tim, 

euterpe/verilog/bsrc/pimlib.pl contains this : 

/'^\s*(\S+)\s+(\S+)\s+(\S4-)\s*(.*)/ && do { 
printf ("%s%s\t %g\t %g\t %s\n", 

$inst, $1, $2 + $baserow, $3 + Sbasecol, 

(($4 && (substr($4,0,l) ne "#"))? $inst.$4 : $4)); 

in the shiftpim_v subroutine 

Thi sdoes not work because of the $inst.$4 : $4 

Usually, in the pirn files that I see, $4 is someting like <1934 and is an 
alignment mark for pimpif. Adding the Sinst does not work . 

Do you remember whay that was added. Are there cases where this is necessary 
but 1 havent seen yet. 

I saw tiie mail's going by from hopper, but I have no idea what if s 


I think he was working with dickson. Best thing would be to get mark 
to patch up the shiitpim to be compatible with whatever new stuff is 
allowed in .pim files. 


for. 


Tim 
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From: Tim B. Robinson [tbr@gamorra] 

Sent: Saturday, November 05, 1994 8:23 PM 

To: 'Geert Rosseel* 

Cc: 'hopper@gamorra' 

Subject: euterpe/verilog/bsrc/pimlib.pl 


Geert Rosseel wrote (on Sat Nov 5) : 


Hi Tim, 

euterpe/verilog/bsrc/pimlib.pl contains this : 

/"\s*{\S+)\s+{\S+)\s+(\S+)\s*{.*)/ &t do { 

printf {"%s%s\t %g\t %g\t %B\n", 

$iiist, $1/ $2 + $baserow, $3 + $basecol, 
(($4 (substr($4, 0,1) ne "#"))? 

$inst.$4 : $4)); 

in the shiftpim_v subroutine 

Thi sdoes not work because of the $inst.$4 : $4 

Usually, in the pirn files that I see, $4 is someting like <1934 and is an 
alignment mark for pimpif . Adding the $inst does not work . 

Do you remember whay that was added. Are there cases where this is necessary 
but I haven't seen yet. 

I saw the mail's going by from hopper, but I have no idea what it's for. 

I think he was working with dickson. Best thing would be to get mark to patch up the 
shiftpim to be compatible with whatever hew stuff is allowed in .pim files. 

Tim 
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From: Mark Hofmann [hopper@boreas] 

Sent: Saturday, November 05, 1 994 8:27 PM 

To: Tim B. Robinson' 

Cc: 'geert@ghidra'; 'hopper@gamorra' 

Subject: Re: euterpe/verilog/bsrc/pimlib.pl 


Tim B. Robinson writes: 

Geert Rosseel wrote (on Sat Nov 5) : 
Hi Tim, 

euterpe/verilog/bsrc/pimlib.pl contains this : 

/"\s*(\S+)\s+(\S+)\s+(\S+)\s*(.*)/ && do { 

printf ("%s%s\t %g\t %g\t %s\n", 

$inst, $1, $2 + $baserow, $3 + $basecol, 
(($4 Se& (siabstr ($4,0,1) ne "#"))? 

$inst.$4 : $4)); 

in the shiftpim_v siibroutine 

Thi sdoes not work because of the $inst.$4 : $4 

Usually, in the pim files that I see, $4 is someting like <1934 and is an 
alignment mark for pimpif . Adding the $inst does not work . 

Do you remember whay that was added. Are there cases where this is necessary 
but I haven't seen yet. 

I saw the mail's going by from hopper, but I have no idea what it's 
for. 

I think he was working with dickson. Best thing would be to get mark 
to patch up the shiftpira to be compatible with whatever new stuff is 
allowed in .pirn files. 

Tim 

I didn't work on this file, but I think I understand what's happened. 

the alignment marks of the type that Geert is seeing "<1934" are fairly new. They are 
really "bounds" marks which constrain a cell placement. 
At any rate, I will attempt to patch pimlib.pl 

-hopper 
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From: Mark Hofmann [hopper@boreas] 
Sent: Saturday, November 05, 1994 8:28 PM 
To: Tim B. Robinson' 
Subject: Re: Top level Makefile 

Tim B. Robinson writes: 
Tom Vo wrote (on Sat Nov 5); 
I'm still waiting for the snapshot proteus to get updated . 
When that's done , 1*11 start the euterpe rebuild . 
When that's done , you can launch your DRC and fracture . 

The first make just completed (exit 1). This was expected because of 
the disk full and license problems. Brianl has cleaned up the bogus 
tuning files that wer created and I have restarted the make. 
Hopefijlly only about 10% of them should need running on this pass. 

I'll page if I get it to complete successfully. 
Tim 

Let me know too, please! 

-thanks, 
hopper 
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From: 


tbr 

Saturday, November 05, 1994 8:38 PM 
'Mark Hofmann' 

'geert@ghidra'; 'hopper@gamorra' 
Re: euterpe/verilog/bsrc/pimlib.pl 


Sent: 

To: 

Cc: 


Subject: 


Follow Up Flag: Follow up 
Flag Status: Red 

Mark Hofinann wrote (on Sat Nov 5): 

Tim B. Robinson writes: 
Geert Rosseel wrote (on Sat Nov 5): 
Hi Tim, 

euterpe/verilog/bsrc/pimlib.pl contains this : 

/A\s*(\S+)\s+(\S+)\s+(\S+)\s*(.*)/ && do { 
printf ("%s%s\t %g\t %g\t %s\n", 

$inst, $] , $2 + Sbaserow, $3 + $basecol, 

(($4 && Csubstr($4,0,l) ne "#"))? $inst.$4 : $4)); 

in the shif^im_v subroutine 

Thi sdoes not work because of the $inst.$4 : $4 

Usually, in the pim files that I see, $4 is someting like <1934 and is an 
alignment mark for pimpif Adding the Sinst does not work . 

Do you remember whay that was added. Are there cases where this is necessary 
but I haven't seen yet. 

I saw the mail's going by irom hopper, but I have no idea what it's 
for. 

I think he was working with dickson. Best thing would be to get maik 
to patch up the shiftpim to be compatible with whatever new stuff is 
allowed in .pim files. 


I didn't work on this file, but I think I understand what's happened, 
the alignment marks of the type that Geert is seeing "<1934" are fairly 
new. They are really "bounds" marks which constrain a cell placement. 

At any rate, I will attempt to patch pimlib.pl 

Sorry, I meant that you had been working on pim/pif to add 
iunctionality that this fell probably does not track. 


Tim 


Tim 
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Sent: 


To: 


Subject: 


From: 


tbr 

Saturday. November 05, 1994 8:39 PM 

'Mark Hofmann' 

Re: Top level Makefile 


Follow Up Flag: Follow up 
Flag Status: Red 

Mark Hofinann wrote (on Sat Nov S): 

Tim B. Robinson writes: 
Tom Vo wrote (on Sat Nov 5): 
I'm still waiting for the snapshot proteus to get updated . 
When that's done , I'll start the euterpe rebuild . 
When that's done , you can launch your DRC and fracture . 

The first make just completed (exit 1). This was expected because of 
the disk full and license problems. Brianl has cleaned up the bogus 
timing files that wer created and I have restarted the make. 
Hopefully only about 10% of them should need running on this pass. 

ril page if I get it to complete successfully. 
Tim 

Let me know too, please! 

I'm worried brian may have removed the wrong files. The restart is 
now remaking the leaf cells, but it did not re-run any lobe tuning 
runs when I restarted it. 


Trni 
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From: Mark Hofmann [hopper@boreas] 
Sent: Saturday, November 05, 1994 8:40 PM 
To: Tim B. Robinson' 
Subject: Re: euterpe/verilog/bsrc/pimlib.pl 

Tim B. Robinson writes: 
Sorry, I meant that you had been working on pim/pif to add 
functionality that this feil probably does not track. 

No problem. Now I have to sharpen up my Perl skills! 

-hopper 
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From: 


tbr 


Sent: 


Subject: 


To: 


Saturday. November 05, 1994 8:41 PM 
'Mark Hofmann' 

Re: euterpe/verllog/bsrc/pi mlib.pl 


Follow Up Flag: Follow up 
Hag Status: Red 

Mark Hofmann wrote (on Sat Nov S): 

Tim B. Robinson writes: 
Sorry, I meant that you had been working on pim/pif to add 
functionality that this feil probably does not track. 

No problem. Now I have to sharpen up my Perl skills! 

Good for the soul. 
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From: 
Sent: 


tbr 


To: 


Saturday, November 05, 1994 9:01 PM 
'Mark Hofmann' 


Cc: 


'brianl' 


Subject: 


Re: Top level Makefile 


Follow Up Flag: Follow up 
Flag Status: Red 

Mark Hofinann wrote (on Sat Nov 5): 

Tim B. Robinson writes: 
Could be, but if he actually removed 60 odd files, those ones would 
have to run since there would be no timestamp. Nothing re-ran. 

Hmm. Okay, I'm not sure what's going on. 

Do you have any idea how long the leafmold run is? 

I think a full run takes a good fraction of a day (depending on how many 
gards licenses are available). Hopefully, though, only the 25-or-so failing 
cells will be attempted which ought go pretty quick. 

No, ot's worse than that. For reasons brian could not fully explain, 
the timing characterixation was run for all lobes. Order 60 failed 
and he said he removed the results. Now it appears that it is 
remaking all the leafcell layouts: 

tbr@gamorra /n/auspex/s41/euterpe-snapshot/euterpe/proteus/leafgen/leafmold 417 % wc -1 *.list.* 

309 tmp.list.hepatu 

310 tmp.list.marathon 
310 tmp.list.merope 
310 tmp. list. psyche 
309 tmp.list.thalia 
1548 total 


There is also another problem that brian was going to look at. Since 
the leafgen Makefile does not actually update the master timing file 
when the run completes, the top level Makefile will charge on leaving 
the timing cata to be copied over by hand. I suggested he put 
something in the top level makefile to do that copy. That would not 
affect a release at the leafgen level whcih would stioll need manual 
intervention t» change the timing file. 

Thinking about it some more, the correct solution would be to have 
another targer in the leafgen Makefile which makes the tmp file and 
then copies it over. The top level proteus Makefile would ask for 
that targer, but the leafgen .checkoutrc would still ask for the 
target that does not do the copy. 


Tim 
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From: Mark Hofmann [hopper@boreas] 
Sent: Saturday, November 05, 1994 9:04 PM 
To: 'Tim B. Robinson' 
Cc: 'briani@gamorra' 
Subject: Re: Top level Makefile 

Tim B. Robinson writes: 
Mo, it's worse than that. For reasons brian could not fully explain, 
the timing characterlxation was run for all lobes. Order 60 flailed 
and he said he removed the results. Now it appears that it is 
remaking all the leafcell layouts: 

tbr@gamorTa/n/auspex/s41/eutfirpe-snapshot/euterpe/proteus/leafgen/leafinold 417 % wc -1 ♦.list.* 

309 tmp.list.hepatu 

310 tmp.listmarathon 
3 10 tmp.list.merope 
310tmp.list.psyche 
309 tmp.list.thalia 
1548 total 

Oops... But there don't appear to be too many leafmold running presently 


There is also another problem that brian was going to look at. Since 
the leafgen Makefile does not actually update the master timing file 
when the run completes, the top level Makefile will charge on leaving 
the timing cata to be copied over by hand. I suggested he put 
somethuig in the top level makefile to do that copy. That would not 
affect a release at the leafgen level whcih would stioll need manual 
intervention to change the timing file. 

Thinking about it some more, the correct solution would be to have 
another targer in the leafgen Makefile which makes the tmp file and 
then copies it over. The top level proteus Makefile would ask for 
that targer, but the leafgen .checkoutrc would still ask for the 
target that does not do the copy. 

Yes, that sounds like the right approach. 

Tim 

-hopper 
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From: 


tbr 


To: 
Cc: 

Subject: 


Sent: 


Saturday, November 05, 1994 9:26 PM 

Tom Laidig' 

'hopper*; 'brlnal' 

Re: pager log message 


Follow Up Flag: Follow up 
Flag Status: Red 


Tom Laidig wrote (on Sat Nov 5): 

Tim B. Robinson writes: 
I 

Ipage from tbr to tom: 

jtrouble with proteus snapshot update 338 41 52. tbr 

I've just scanned a couple email messages, and am cleaning the junk out 
of merope:Aisr/tmp. What else should I be doing? 

Perhaps you could do some poking in the snapshot to assess the damage. 
Here's the history. I started up a top level Make in the s23/proteus. 
For whatever reason, it decided to re-run all the lobe timing. 
There were 2 problems, merope:/tmp full which according to brianl 
causes jobs to die, but with spice returning a success error code. 
Second, there was a problem witfi mercury (I think) not being able to 
get a spice license for some reason. That caused another bunch of 
things to die, but without creating results (according to brian). 
So, brian said he was removeing around 60 bogus outputs files from the 
jobs that went to merope, and he then took the 2 bad machines off the 
deal list. The run died when deal finally finished with exitl. 

I then restarted the Make, expecting it to re-run the missing cases, 
but instead it went on to make the leafcell layouts and as far as I 
can see did not try to re-run any timing. Of course then I ran into 
the merope problem with the leafinold runs dying there, so we now 
possibley have another bunch of bad stuff. 

Since the timmg did not re-run I'm worred brian removed files in the 
wrong place. If you could take a look through the makerrs in 
/n/auspex/s41/euterpe-snapshot/euterpe/proteus you will see the 
history. (The current run is being appended.) Please see if you can 
tell if the results of the dying jobs did indeed get removed, and if 
so, why the new run did not remake them. 

One possibly relevant fact is that between the runs I discovered we 
did not have the latest top level Makefilee in the proteus snapshot 
so I updated and releasebommed that file. It came up 3 revisions. 
It's just possible the reason the timing has not re-run is because of 
some ordering change between those versions. 

Let me know what you find. 


Thanks 
Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Tim B. Robinson [tbr@gamorra] 
Saturday, November 05, 1994 9:32 PM 
'Patricia Mayer' 

'albers@aphroclite'; 'glen@gamorra'; 'hestla@aphrociite'; 'philip@aphrodite'; 

'pmayer@aphrodite' 

Re: prl review 


Patricia Mayer wrote (on Thu Nov 3) : 

Another part issue that Philip mentioned was a fuducial mark for Caliope 
and Euterpe. ?? 

I think this was worked out for the TAB test board and as far as I know we said long ago 
we would go with the same. Maybe it never made it into the prt. I assume glen has a 
version in PCAD somewhere. 


Tim 
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From: Tom Laidig [tom@ciio] 

Sent: Saturday, November 05, 1 994 9:43 PM 

To: Tim B. Robinson' 

Cc: 'Mark Hofmann'; 'Brian Lee'; 'Thomas Laidig' 
Subject: Re: pager iog message 

Tim 6. Robinson writes: 


jTom Laidig wrote (on Sat Nov 5): 

I Tim B. Robinson writes: 

I I 

I Ipage from tbr to torn : 

I jtrouble with proteus snapshot update 338 4 152. tbr 

I Tve just scanned a couple email messages, and am cleaning tiie junk out 

I of merope:/usr/tmp. What else should 1 be doing? 

jPerhaps you could do some poking in the snapshot to assess the damage. 
IHere's the history. I started up a top level Make in the s23/proteus. 
|For whatever reason, it decided to re-run all the lobe timing. 
IThere were 2 problems, merope:/tmp full which according to brianl 
jcauses jobs to die, but with spice returning a success error code. 
[Second, there was a problem with mercury (I think) not being able to 
jget a spice license for some reason. That caused another bunch of 
[things to die, but without creating results (according to brian). 
jSo, brian said he was removeing around 60 bogus outputs files from the 
[jobs that went to merope, and he then took the 2 bad machines off the 
Ideal list. The run died when deal finally finished with exitl. 

I I then restarted the Make, expecting it to re-run the missing cases, 
jbut instead it went on to make the leafcell layouts and as far as I 
jean see did not try to re-run any timing. Of course then 1 ran into 
jthe merope problem with the leafinold runs dying there, so we now 
jpossibley have another bunch of bad stuff. 

jSince the timing did not re-run I'm worred brian removed files in the 
jwrong place. If you could take a look through the makerrs in 
|/n/auspex/s41/euterpe-snapshot/euterpe/proteus you will see the 
jhistory. (The current run is being appended.) Please see if you can 
jtell if the results of the dying jobs did indeed get removed, and if 
jso, why the new run did not remake them. 

jone possibly relevant fact is that between the runs I discovered we 
jdid not have the latest top level Makefilee in the proteus snapshot 
jso I updated and releasebommed that file. It came up 3 revisions, 
jit's just possible the reason the timing has not re-run is because of 
jsome ordering change between those versions. 

[Let me know what you find. 

OK, the change in toplevel Makefile is important. The (version 1 .21) 
Makefile said 
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$(MAKE) -C leafgen eveiything 

while the new (version 1 .24) one says 

$(MAKE) -C leafgen all 

I think there's some funky history involved in this, but anyway at the 
present the 'all' target in leafgen/Makefile does more than the 
'everything' target. Specifically, it runs the make in the leafinold 
subdirectory before doing the timing stuff. So it's not a matter that 
the timing stuff didnt get rerun; it just hasn't happened yet. I don't 
think I understand what happens in the leafgen Makefile well enough to 
figure out whether brianl did the proper surgery there or not. 

BTW, one reason that merope's temp area was full (both /tmp and /usr/tmp 
are on the /usr disk) is a problem in leafinold. For the most part, if s 
pretty careful to clean up after itself if it fails, but I missed a 
case: if it failed because the first cp of files into its temporary 
directory (/usr/tmp/leaftnold.<cellname>) failed, it just exited. It 
appears that, when 1 did a big leafinold test run on thursday, the disk 
was full, and then whatever else had filled it slowly freed up space. 
Unfortunately, each successive leafinold process filled what was left, 
then died uncleanly. I have a fixed version in my local area, which I'll 
check in after some testing. 


TomL 
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From: Tom Vo [vo@merope] 

Sent: Saturday, November 05, 1994 9:45 PM 

To: Tim B. Robinson' 

Cc: 'geert@merope'; 'hopper@merope'; 'iisar@merope'; 'tom@merope'; Vanthof@merope'; 

'wampler@merope' 
Subject: Re: proteus snapshot stale 


Tim B . Robinson wrote .... 

>If you are held up for this, I will try and figure out which makes to 
>run to get it updated. The timing run is still going in the top level 
>inake. 
> 

>Tim 


I think for the lower layer euterpe baseplate , we just need to run proteus /dcell and 
proteus/gards . checkoutrc to get the new gtlb footprint . 

The new timing number may change how some of the gardswart blocks are built so there's a 
bit a exposure there . If my run completes before the gardswart rebuild , my netlist 
could be out of syn wrt the layout . 

But the lower layers for the gardswarts should not change . 


tvo 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Tim B. Robinson [tbr@gamorra] 
Saturday, November 05, 1994 9:49 PM 
Tom Vo' 

•geert@merope'; 'hopper@merope'; 'lisar@merope*; 'tom@merope'; Vanthof@merope'; 

'wampler@merope' 

Re: proteus snapshot stale 


Tom Vo wrote (on Sat Nov 5) : 
Tim B, Robinson wrote .... 

>If you are held up for this, I will try and figure out which makes to 
>run to get it updated. The timing run is still going in the top level 
>make , 


I think for the lower layer euterpe baseplate , we just need to run 
proteus/dcell and proteus/gards .checkoutrc to get the new gtlb footprint . 
The new timing number may change how some of the gardswart blocks are built 
so there ' s a bit a exposure there . If my run completes before the 
gardswart rebuild , my netlist could be out of syn wrt the layout . 
But the lower layers for the gardswart s should not change . 

I'll fire up runs in those areas now. 


> 


>Tim 


Tim 
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From: Mark Hofmann [hopper@boreas] 

Sent: Saturday, November 05, 1994 9:50 PM 

To: 'Geert Rosseel'; Tim B. Robinson' 

Cc: 'Tom Vo' 

Subject: new pimlib.pl read to install in euterpe/verilog/bsrc 


I _think_ I've patched the pimlib.pl to handle the new alignment marks correctly. At 
least it works in the testcases that I tried, when can I do a release? 

- thanks , 
hopper 
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From: 
Sent: 
To: 

Subject: 


Mark Hofmann [hopper@boreas] 
Saturday, November 05, 1994 9:52 PM 
'Geert Rosseel' 

output of euterpe/verilog/bsrc/nb/.checkoutrc (fwd) 


Hi geert. 


the NB stuff is released, the exit 1 is because it still fails timing. 


-mark 


Buffalo Chip writes : 

From chip®cyclops Sat Nov 5 17:45:32 1994 
Date: Sat, 5 Nov 1994 17:45:26 -0800 
From: chip@cyclops (Buffalo Chip) 

Message-Id: <199411060145 .RAA22272®cyclops .microunity . com> 
To : hopper@cyclops 

Subject: output of euterpe/verilog/bsrc/nb/ . checkoutrc 

The output from euterpe/verilog/bsrc/nb/ . checkoutrc is 336k, so it is not included 
in this mail message. Instead, check the file 

/n/tmp/chiplog/hopper , cyclops . 16571 . euterpe-verilog-bsrc-nb 

(which is accessible from all machines) . This file will disappear in 
about 5 days. 

By the way, the exit status returned by .checkoutrc was 1. 


-thanks, 
hopper 


thanks , 
mark hofmann 
hopperomicrounity . com 
408 734 8100 
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From; Tom Vo [vo@merope] 

Sent: Saturday, November 05, 1994 9:52 PM 

To: 'Tim B. Robinson' 

Cc: 'geert@merope'; 'hopper@merope'; 'lisar@merope'; 'tom@merope'; 'vanthof@merope'; 

'wampler@nrierope' 
Subject: Re: proteus snapshot stale 


Tim B . Robinson wrote .... 


>Tom Vo wrote (on Sat Nov 5) : 
> 

> Tim B . Robinson wrote . , . . 

> >If you are held up for this, I will try and figure out which makes to 

> >run to get it updated. The timing run is still going in the top 
level 

> >niake . 

> > 

> >Tim 

> > 


> I think for the lower layer euterpe baseplate , we just need to run 

> proteus/dcell and proteus/gards .checkoutrc to get the new gtlb 
footprint . 

> The new timing number may change how some of the gardswart blocks 

> are 

built 

> so there's a bit a exposure there . If my run completes before the 

> gardswart rebuild , my netlist could be out of syn wrt the layout . 

> But the lower layers for the gardswart s should not change . 
> 

>i'll fire up runs in those areas now, 

> 

>Tim 


You'll need to run them in sequence : dcell , then gards 

thanks 

tvo 
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From: tbr 

Sent: Saturday, November 05, 1994 9:52 PM 

To: 'Mark Hofmann' 

Cc: 'Geert Rosseel'; Tom Vo' 

Subject: new pimlib.pl read to install in euterpeA/erilog/bsrc 

Follow Up Flag: Follow up 

Flag Status: Red 


Mark Hofmami wrote (on Sat Nov 5): 


Hi, 

I thmk_ I've patched the pimlib.pl to handle the new alignment marks 
correctly. At least it works in the testcases that I tried, when can I 
do a release? 

Any time is OK for me. 

Tim 
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Sent: 

To: 

Cc: 


Subject: 


From: 


Tim B. Robinson [tbr@gamorra] 

Saturday, November 05, 1994 9:52 PM 

'Mark Hofmann' 

'Geert Rosseel'; Tom Vo' 

new pimlib.pl read to install in euterpe/verilog/bsrc 


Mark Hofmann wrote (on Sat Nov 5) : 


Hi, 

I _think_ I've patched the pimlib.pl to handle the new alignment marks 
correctly. At least it works in the testcases that I tried, when can I 
do a release? 

Any time is OK for me. 


Tim 
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From: Tim B. Robinson [tbr@gamorra] 

Sent: Saturday, November 05, 1994 9:54 PM 

To: Tom Vo' 

Cc: 'geert@merope'; 'hopper@merope'; 'lisar@merope'; 'tom@merope'; 'vanthof@merope'; 

'wampler@merope' 
Subject: Re: proteus snapshot stale 


Tom Vo wrote (on Sat Nov 5) : 
Tim B . Robinson wrote .... 


>Tom Vo wrote (on Sat Nov 5) i 


to 

level 


Tim B. Robinson wrote .... 

>If you are held up for this, I will try and figure out which makes 

>run to get it updated. The timing run is still going in the top 

>make . 
> 

>Tim 


> I think for the lower layer euterpe baseplate , we just need to 

run 

> proteus/dcell and proteus/gards .checkoutrc to get the new gtlb 
footprint . 

> The new timing number may change how some of the gardswart blocks 
are built 

> so there ' s a bit a exposure there . If my run completes before the 

> gardswart rebuild , my net list could be out of syn wrt the layout . 

> But the lower layers for the gardswart s should not change . 
> 

>l'll fire up runs in those areas now. 
> 

>Tim 


You'll need to run them in sequence : dcell , then gards 
Yes. Dcell is running now, but I see: 


ERROR -- can't find cell "XBLDH4S' {boo file " , . /coropass/vlsi .boo-all ' ) ERROR -- can't 
find cell ^XBORL2DH4S' (boo file ^ .. /compass/vlsi . boo-all ' ) ERROR can't find cell 
"XBORL2DF4S' (boo file " . . /compass/vlsi . boo-all ' ) ERROR -- can't find cell "•XBORL3DF4S' 
(boo file .. /compass/vlsi. boo-all • ) ERROR -- can't find cell "XBLDP4S' (boo file 
. . /compass/vlsi .boo-all ' ) 

It seems to be continuing though. 

Tim 
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Sent: 

To: 

Cc: 


Subject: 


From: 


Tom Vo Ivo@merope] 

Saturday, November 05, 1994 9:55 PM 

'Mark Hofmann' 

'geert@boreas'; 'tbrOboreas'; 'vo@boreas' 

Re: new pjmlib.pl read to install in euterpe/verilog/bsrc 


Mark Hofmann wrote .... 


>Hi, 
> 

> I _think_ I've patched the pimlib.pl to handle the new alignment 
>marks correctly. At least it works in the testcases that I tried, when 
>can I do a release? 

> 

> -thanks, 

> hopper 


lOam and 5pm of course , You should know better -- you're the official release police 


tvo 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Mark Hofmann [hopper@boreas] 

Saturday. November 05, 1994 9:56 PM 

Tim B. Robinson' 

'geert@boreas'; 'vo@boreas' 

Re: new pimlib.pl read to install in euterpeA/erilog/bsrc 


Tim B . Robinson writes : 
hopper writes : 

I _think_ I've patched the pimlib.pl to handle the new alignment marks 
correctly. At least it works in the testcases that I tried, when can I 

do a release? 

Any time is OK for me. 


Okay, I've just done a of pimlib.pl only in th euterpe/verilog/bsrc directory. 


Tim 


-hopper 
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From: 
Sent: 
To: 

Subject: 


tbr 


Saturday. November 05, 1994 9:56 PM 
'dickson' 

forwarded message from Guillermo A. Loyola 


Follow Up Flag: Follow up 
Flag Status: Red 

What's the last word on shift overflows 

Start of forwarded message 

Status: RO 

X-VM-v5-Data: ([nil nil nil nil t nil nil nil nil] 

["354" "Thu" "3" "November" "94" "17:31:10" "-0800" "Guillermo A. Loyola" "gmo@bilbo " 
"<941 1040 1 3 1 .AA 1 8003@bilbo>" "7" "Re: shift overflow instructions" "-^From:" nil nil " 1 1 "]) 
Return-Path: <gmo@bilbo> 

Received: from rimulac.microunity.com by gaea.micromiity.com (4.1/musel.3) 

id AA 16837; Thu, 3 Nov 94 17:3 1: 19 PST 
Received: from bilbo by rimulac.microunity.com (8.6.4/muse-sw.2) 

id RAA28463; Thu, 3 Nov 1994 17:31:17 -0800 
Received: by bilbo (931 1 10.SGI.ANONFTP/930416.SGI) 

for veena@rimulac.microunity.com id AA 18003; Thu. 3 Nov 94 17:31 : 10 -0800 
Message-Id: <94 1 1 040 1 3 1 . AA 1 8003@bilbo> 
From: gmo@bilbo (Guillermo A. Loyola) 

To: tbr@rimulac, lisar@rimulac, jeffrn@rimulac, veena@rimulac (Veena Malwankar) 
Cc: dickson@bilbo 

Subject: Re: shift overflow instructions 
Date: Thu, 3 Nov 94 17:31:10 -0800 

I though Rich was still looking at possibly implementing those using the 1ms hardware. 
Otherwise 1 guess I'll have to change terp to be bug-compatible with the hardware 
(Bug because if the instruction does not do what it is supposed to it just shouldn't 
be there, but yea I know, checking for it to produce the exceptions is more atomes, right?). 

Gmo. 

End of forwarded message 
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From: Mark Hofmann [hopper@boreas] 

Sent: Saturday, November 05, 1994 9:57 PM 

To: Tom Vo' 

Cc: 'geert@boreas'; 'tbr@boreas'; •vo@boreas' 

Subject: Re: new pimlib.pl read to Install In euterpeA/erilog/bsrc 


Tom Vo writes: 

10am and 5pm of course , You should know better 
you're the official release police :-) 

Oops ! 

(Luckily, I got this mail _after_ I had already done the release!) 
-hopper 
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From: tbr 

Sent: Saturday, November 05, 1994 10:02 PM 

To: 'Mark Hofmann' 

Cc: 'geert@boreas'; 'vo@boreas'; Tom Vo' 

Subject: Re: new pimlib.pl read to install in euterpeA^erilog/bsrc 


Follow Up Flag: Follow up 
Flag Status: Red 

Mark Hofmann wrote (on Sat Nov 5): 

Tom Vo writes: 

10am and 5pm of course . You should know better - 
you're the official release police >) 

Oops! 

(Luckily, I got this mail _after_ I had already done the release!) 
I tiiink that rule really only applies to proteus. . . 
Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Tim B. Robinson [tbr@gamorra] 
Saturday, November 05, 1994 10:02 PM 
'Mark Hofmann' 

'geert@boreas'; 'vo@boreas'; Tom Vo' 

Re: new pimlib.pl read to install in euterpe/verilog/bsrc 


Mark Hofmann wrote (on Sat Nov 5) : 

Tom Vo writes: 

10am and 5pm of course . You should know better -- 
you're the official release police :-) 

Oops ! 

(Luckily, I got this mail _after_ I had already done the release!) 
I think that rule really only applies to proteus. . . 


Tim 
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From: 


tbr 


To: 


Sent: 


Subject: 


Saturday. November 05, 1994 10:10 PM 
'torn' 

ged makefile 


Follow Up Flag: Follow up 
Flag Status: Red 


Is it significant that whenever I restat the top level Make it ahvays 

does: 

gmake -C ged config- files 

gmake[l]: Entering directory VN/auspex/root/slS/euterpe-proteus-qj/ged' 

for LIB in " aa ad af bb cl bg ca eg cr ct ea gt io led lo mb pa pi ra ram rd ix sc spice sy test ttl ts vd vr xa xb xbq xc devices 
primitives doc ; do \ 

if [ -z "$LIB" ] ; then continue; fi; \ 
if[!-f$LIB/$LIB.lib];then\ 
mkdir -p $LIB; \ 

echo ■FILE_TYPE = SPICE__DIR;' > $LIB/$LlB.lib; \ 
echo 'END/ » $LIB/$LIB.lib; \ 

fi;\ 

CHIPROOT=/n/auspex/s23/euterpe-proteus-cp /n/auspex/s23/euterpe-proteus-cp/tools/bm/mkgedUb -cluS $LIB; \ 


done 


Tim 
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From: 
Sent: 
To: 

Subject: 


tbr 

Saturday, November 05, 1994 10:15 PM 
'dickson' 

forwarded message from Craig Hansen 


Follow Up Flag: Follow up 
Flag Status: Red 

Start of forwarded message 

Status: RO 

X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] 

["3001" "Fri" "4" "November" "1994" "10:54:57" "-0800" "Craig Hansen" "craig@mnemosyne " nil "67" "Re: bring-up 
meeting of November 2" "^From:" nil nil "11"]) 
Return-Path: <craig@mnemosyne> 

Received: from mnemosyne.microunity.com by gaea.microunity.com (4,l/musel.3) 

id AA 15779; Fri, 4 Nov 94 10:55:02 PST 
Received: from localhost by mnemosyne.microunity.com (8.6.4/muse-sw.2) 

id KAA 14379; Fri, 4 Nov 1994 10:54:57 -0800 
Message-Id: <19941 1 041 854.KAA14379@mnemosyne.microunity.com> 
From: craig@mnemosyne (Craig Hansen) 
To: craig@echidna, wayne@echidna 
Cc: euterpe@mnemosyne 
Subject: Re: bring-up meeting of November 2 
Date: Fri, 4 Nov 1994 10:54:57 -0800 

Wayne wrote: 

> Ask Craig if an abort invalidates the byte in transit 

> or the entire packet. (Wayne) 

Craig, I was given an action item to verify a question with you. 
When an Abort is issued, is the byte only invalidated, or is the 
entire packet be invalidated. In addition, is there a specific time 
response for the sending device to respond to the Abort (retransmit) 
before another device grabs the bus, or is it first come first serve 
here? 

Thanks, 

Wayne 

Craig responds: 

An abort, in which the SD line is driven low for 12-22 cycles, 
causes the entire transaction to be aborted. This is more extensive 
than the choices you gave me (byte in transit or the entire packet); 
the entire transaction is aborted, no matter whether the current 
packet is a request or response, [see page TSA 14-Apr-94 page 294.] 

After an abort, the next transaction may begin immediately upon 
seeing SD high for one cycle (which ends the abort) [Page 294]. 
A device which has lost the arbitration of a collision, or has 
suffered the occurrence of a transaction abort, may retry the 
transmission immediately [Page 296], All other devices must wait 
one additional cycle before transmitting, ensuring that 
all devices which have collided perform their operations before 


Exhibit C8 


Page 195 of 598 


another set of devices arbitrate again [Page 296]. It may be noted 
that other devices which were arbitrating for access at the 
same time as the device which initiated the aborted transaction 
get the opportunity to respond at the same time as the 
previous initiator; provided that the contents of the requests 
are the same as the previous transaction, the result of 
the arbitration on the retransmitted transaction 
should be the same as the previous, aborted, transaction. 

The above mechanism might appear to ensure that an transaction 
initator, one having begin a transaction can simply assume that 
it need not worry about another transaction grabbing the bus 
away. However, this is not the case. Firstly, a transaction 
abort may occur before arbitration has been completed on 
the local Cerberus bus, and tfie initator may lose arbitration 
on the retransmission. The initator must be prepared to 
accept the loss of arbitration, even when the loss implies 
that it must respond as a target of the transaction. 
Secondly, gateways and repeaters may need to apparently 
override the local fairness mechanism to ensure global 
fairness or to avoid system deadlock, and in such cases, 
may begin a retransmission immediately upon the end of 
an abort even though it wasnt among the set of initiators 
of the previous transaction, [see page 307] 

Also, a device which requires a delay after an aborted transaction 
may force the delay bit after the first byte of the immediately 
following transaction, and may cause the first byte to be 
re-transmitted by aborting the following transaction after 
requesting a suitable delay [page 297]. 

Regards, 
Craig 


End of forwarded message 
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From: 
Sent: 
To: 

Subject: 


Tom Vo [vo@merope] 

Saturday, November 05, 1994 10:16 PM 

'Fred Obermeier*; 'Geert Rosseel'; 'Mark Hofmann'; Tim B, Robinson'; 'Dave Van't Hof 
proteus/baseplate 


I came across some illegal tool usage in proteus/Makef ile .base such as vlsimm instead of 
$ (VLSIMM) and was getting ready to fix thera when the following message caught my eyes . 


RCS file: /p/cvsroot/proteus/baseplate/Makef ile. base, V 

Working file: Makefile .base 

head: 1.64 

branch : 

locks: strict 

access list: 

symbolic names : 

comment leader: "# " 

keyword siibstitution: kv 

total revisions: 64; selected revisions: 64 
description: 


revision 1,64 

date: 1994/10/20 18:07:08 LT; author: fwo; state: Exp; lines: +1 -4 Remove support for 
old pad type: custom_vdd_j5ad. it's not used by calliope or euterpe. 


I know for a fact the the custom block cr on euterpe uses this cell . We should chase 
this one down . Fred ??? 


tvo 
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Sent: 


To: 


Subject: 


From: 


tbr 

Saturday. November 05. 1994 10:19 PM 
'doi'; 'jeffm'; 'lisar' 
Makefile problem 


Follow Up Flag: Follow up 
Flag Status: Red 


There is something wrong in one of the proteus Makefiles. In 
attempting to get the proteus snapshot up to date I have had to 
restart the top level Makefile several times, It repeatedly remakes 
some Zycad bmods. Clearly I would expect this only to happen once: 

S.la/XPLUS5.1a^in/bmodlib -add ./xpdir SDRAM.bmod 
Updating "SDRAM.bmod"... 
xpdir/SDRAM .bmod: 
xpdu-ZSDRAM.c: 

LM_LICENSE_FILE=/n/auspex/s23/euterpe-proteus-cp/tools/vendor/zycad/license/license.dat CASE_nsISENSITIVE=^ 
ZYCAD=/n/auspex/s23/euterpe-proteus-cp/tools/vendor/zycad.5. la XPLUS_VER=5. la /n/auspex/s23/euterpe-proteus- 
cp/tools/ve^dor/zycad.5.1a/XPLUS5.1a/bi^/bmodlib -add ./xpdir SNOOPY.bmod ceitsnoop.o 
Updating "SNOOPY.bmod"... 
Updating "cerbsnoop.o"... 
xpdir/SDRAM .bmod: 
xpdir/SDRAM.c: 
xpdir/SNOOPY.bmod: 
xpdir/SNOOPY.c: 

LM_LICENSE_FILE=/n/auspex/s23/euterpe-proteijs-cp/tools/vendor/2ycad/license/Ucense.datCASE_INSENS 

ZYCAD=/n/auspex/s23/euterpe-proteus-cp/tools/vendor/zycad.5. la XPLUS_VER'*5. 1 a /n/auspex/s23/euterpe-proteus- 

cp/tools/vendor/zycad.5.1a/XPLUS5.1a/bin/bmodlib -add ./xpdir HERMES.bmod he.o 

Updating "HERMES.bmod"... 

Updating "he.o"... 

xpdir/HERMES .brnod: 

xpdir/HERMES.c: 

LM_LICENSE_nLE=/n/auspex/s23/eutetpe-proteus-cp/tools/vendor/zycad/Iicense/license.datCASE_INSENSITIVE=^ 

ZYCAD=/n/auspecK/s23/euterpe-proteus-cp/tools/vendor/2ycad.5. la XPLUS_VER=5. 1 a /n/auspex/s23/euterpe-proteus- 

cp/tools/vendor/zycad.5,la/XPLUS5.1a^in/bmodlib -add ./xpdir HC_ARCH.bmod hwjf.o 

Updating "HC^ARCH.bmod"... 

Updatmg "hw if.o"... 

xpdir/HC_ARCH .bmod: 

xpdir/HC_ARCH.c: 

/bin/mv ./xpdir/* .edifZ ../zeblib 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Mark Hofmann [hopper@boreas] 
Saturday, November 05, 1994 10:28 PM 
'Tom Vo' 

'fwo@merope'; 'geert@merope'; 'hopper@merope'; 'tbr@merope'; 'vanthof@merope' 
Re: proteus/baseplate 


Tom Vo writes: 
[snip] 


revision 1.64 

date: 1994/10/20 18:07:08 LT; author: fwo; state: Exp; lines: +1 -4 
Remove support for old pad type: custom__vdd_pad. It's not used by calliope 
or euterpe. 


I know for a fact the the custom block cr on euterpe uses this cell . 
We should 

chase this one down . Fred ??? 


Okay. Indeed you appear to be correct: 


cr2a.ly:# "12-Sep-94 GMT" "22:03:23 GMT" "12-Sep-94 GMT" "22:01:07 GMT" 
efelias * .ly crclkintS crclkint4 crclkintv crclkintS crarray crl2isrc crbbcstm 
crbellybutt custom_vss_pad custom_vdd_pad npolylwafl cr2apwaf borderpwr . 

cr2a.ly:R "il57" 24960 10560 Rotl " custom_vdd_j)ad" layout ""4 1 -7680 0 cr2a.ly:I "il27" 
32640 10560 Rot 1 " cus tom_vdd_pad " layout " " 

cr2a.ly:l "il2l" 40320 10560 Rotl "custom_vdd_pad" layout "" 

cr2a.ly:R "ill9" 71040 10560 Rotl "cuBtom_vdd_j)ad" layout "" 4 1 -7680 0 

cr3a.ly:# "12 -Sep- 94 GMT" "17:41:23 GMT" "12 -Sep- 94 GMT" "17:39:02 GMT" 

efelias * .ly crclkint5 crclkintb crclkinta crl2isrc nwaff4u cr3pgsas crbbcstm crbellybutt 
crdindrvs custom_vss_pad custom_vdd_pad crarray crSapwaf borderpwr . 

cr3a.ly:R "ill2" 24960 2160 Rotl "custom_vdd_j>ad" layout "" 4 1 -7680 0 cr3a.ly:I "i77" 

32640 2160 Rotl " custom_vdd_j)ad" layout 

cr3a.ly:I "i68" 40320 2160 Rotl "custom_vdd_pad" layout 

cr3a.ly:R "i66" 71040 2160 Rotl "custom_vdd_pad" layout 4 1 -7680 0 

At least these 2 cells use custom_vdd_pad . 
Is this cell to be superceded, Fred? 


tvo 


-hopper 
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From: Tom Laidig [tom@clio] 

Sent: Saturday, November 05, 1994 10:53 PM 

To: 'Kurt Wampler' 

Cc: 'hopper@boreas'; 'vo@merope'; 'doi@nosferatu'; 'geert@merope'; 'hopper@merope'; 

'lisar@nosferatu'; 'tbr@merope'; 'tom@nosferatu'; 'vanthof@merope' 
Subject: Re: protection in s41 


Kurt Wampler writes: 

>Mark Hof marm wrote .... 
>> 

>>Tom Vo writes: 
>> 

» It is our friend cp -p , and there 're a few of them , 

>> 

>>Where are they to be found- in a .checkoutrc or Makefile?* 

>> 

>>- hopper 

» 
> 

>They're in the clockbias Makefile : 


>/n/auspex/s41/euterpe- snapshot /euterpe/proteus/clockbias/Makefile . rules ; 
-cp -p cbsof a_model . ly cbsof a_mask. ly cbsof a_exclude. ly $ (BASE) 
I >/n/auspex/s4l /euterpe- snapshot /euterpe/proteus/clockbias/Makefile. rules : 
cp -p $(CPROTO) /cbsofa.tdl . 

I >/n/auspex/s41/euterpe- snapshot /euterpe/proteus/clockbias/Makefile . rules : 
cp -p $ (CPROTO) /clockpairs . rcf . 

I >/n/auspex/s4l/euterpe-snapshot/euterpe/proteus/clockbias/Makefile. rules : 
cp -p $ ^ CPROTO) /clockbias. rcf . 

I >/n/auspex/s4l/euterpe-snapshot/euterpe/proteus/clockbias /Makefile. rules: 
cp -p knob*.ly clockbias. ly cgclockbias. ly $ (BASE) 

I >/n/auspex/s41/euterpe-snapshot/euterpe/proteus/clockbias/Makefile. rules: 
-cp -p $@ $ (BASE) 


>tvo 

Wampler replies: 


,,,and in the gardswarts Makefile, and in virtually every other 
script and Makefile I've produced, the preservation of the date/time 
stamp and protection mode during copy is ^exactly* the behavior I 
want. 

Well, it ain't the behavior _I_ want. I'd rather have gmake know the correct time when a 
file changed, so it can do its job. Have we already forgotten the last time this issue 
came up? The details have happily faded from my memory, but it seems to me we spent at 
least a day chasing some error that we knew we had fixed, but graake didn't know it because 
of a '"cp -p ' . 

As I mentioned before, you've all heard me bellyache about this in the past. To 
reiterate: propagating the tiraestarap of the original file is absolutely, unquestionably* 
incontrovertably _wrong_ for any case where the timestamp of the result is used by gmake 
to determine what it needs to do. It is necessary to have the timestamp reflect the time 
of change of the particular copy of the file that is being used. Using any other 
timestamp is asking for trouble. Besides, who the heck cares what the timestamp of the 
source information was? Do we set the timestamp of each checked out copy of a file to the 
date of the checkin? Of course not i 

I 
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< FLAME 0N> 

I contend that cp ' s failure to deal properly with the case where the 
file is being written imder group permission is a UNIX bug. 

Call it a bug if you like, but it's a pretty inevitable result of the permissions system. 
If you don't own the file, you can't screw with the inode. it would be a bigger mistake 
for "cp -p' to try to force ownership of the file by removing the old and creating a new 
one, since then it will fail if you don't have write permission on the directory. 


I tested the behavior of "cp -p" under SunOS, IRIX, and HP/UX. SunOS 
permits the contents of the file to be copied, but croaks when it 
tries to set permission/timestamp . Under IRIX it copies the 
contents, propagates the date, but does not update the protection 
mode, yet exits with 0 status. Better, but still not correct. 

No, that's worse. It failed to do what you explicitly told it was required, yet it gave 
no error indication. That's what _I_ call a bug. 

BTW, in my test, it didn't propagate the old date (which it couldn't have done, since I 
didn't own the file); it simply acted like a regular cp. 

Under HP/UX, it fails altogether -- it doesn't even copy the 
contents. In fact, a regular "cp" without the "-p" switch fails too. 
When I add "o+w" to my test file, HP/UX copies and sets the date, but 
fails on the mode change. Really brain dead implementation. 

< FLAME OFP> 

I believe adding a in front of the line ahovo which reads: 

cp -p knob*.ly clockbias.ly cgclockbias . ly $ (BASK) 

will alleviate the immediate problem. I have made and releasebom ' ed 
this change. 

ACK! ! ! 

So we'll just ignore whether or not the copy succeeds? I ? 1 ? 

The correct fix is to get rid of the bloody -p option, and quit trying to lie to people 
(6Lnd, worse, programs) about when a file changed. 

Look, I apologize for the strident tone of this message, but this is not an unimportant 
issue, and I had thought we had already hashed it out. I for one am not anxious to be 
called in a _third_ time to help diagnose some screwball problem caused by "cp -p ' . I'm 
going to compile a list of all files in the repository that contain the string "cp -p ' , 
and I strongly recommend we change every one of them, unless there is some specific reason 
why a regular "cp' can't be used instead (I can't imagine what such a reason would be, but 
I'll accept the possibility that it might exist). 


Tom L 
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From: Tom Laidig [tom@clio] 

Sent: Saturday, November 05, 1 994 11 :05 PM 

To: Tim B. Robinson' 

Cc: 'tom@gamorra' 

Subject: Re: ged makefile 

Tim B. Robinson writes: 


jls it significant that whenever I restat the top level Make it always 

jdoes: 

Igmake -C ged config-files 

|gmake[l]: Entering directory '/N/auspex/root/s23/euterpe-proteus-cp/ged' 

jfor LIB in " aa ad af bb cl bg ca eg cr ct ea gt io led lo mb pa pi ra ram rd rx sc spice sy test ttl ts vd vr xa xb xbq xc devices 

primitives doc ; do \ 

I if [ -z "$LIB" ] ; then continue; fi; \ 

I if[!-f$LIB/$LIB.lib];then\ 
j mkdir -p $LIB; \ 

I echo 'FILE_TYPE = SP1CE_DIR;' > $LIB/$LIB.lib; \ 

I echo 'END.' » $LIB/$LIB.lib; \ 

I fi;\ 

I CHIPROOT~/n/auspex/s23/euterpe-proteus-cp /n/auspex/s23/euterpe-proteus-cp/tools/bin/nikgedlib -cluS $LIB; \ 
jdone 

Not particularly. That rule seems to be set up always to run. This 
kinda makes sense, since really it should run any time a new schematic 
is added to (or deleted from) any subdirectory. Getting the 
dependencies right would be hw^er than just rebuilding the xx/xx.Iib 
files. 


TomL 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Tom Laidig [tom@clio] 

Saturday, November 05, 1994 11:10 PM 

Tim B. Robinson' 

'tom@aphrodite'; 'geert@aphrodite'; 'hopper@aphrodite' 
Re: permisions problem 


Tim B. Robinson writes: 

I just tried to fire off a make of the snapshot proteus following the 
getbom. It died immediately because of a permission problem trying to 
update ged/mb/mb. lib. I restarted it as chip and it has got past 
there. Is everything in that tree owned by chip? We have the euterpe 
snapshot set up to be group writeable by cad so people can work there 
without having to su to chip. Since we don't expect too frequent 
changes to proteus it should be no problem having to su, so long as 
everything is consistently owned by chip. 

Hmmm. . . I had thought everything was group -writable in proteus, too, but perhaps some were 
missed. I think it's safer for proteus to just do everything as chip. 


Tom L 
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From: tbr 

Sent: Saturday, November 05, 1 994 11 :21 PM 

To: Tom Laidig' 

Cc: 'geert@aphrodite'; 'hopper@aphrodite'; 'tom@aphrodite' 

Subject: Re: permisions problem 
Follow Up Flag: Follow up 

Flag Status: Red 


Tom Laidig wrote (on Sat Nov 5): 

Tim B. Robinson writes: 
I 

|I just tried to fire off a make of the snapshot proteus following the 
jgetbom. It died immediately because of a pennission problem trying to 
jupdate ged/mb/mb.lib. I restarted it as chip and it has got past 
jthere. Is everything in that tree owned by chip? We have the euterpe 
jsnapshot set up to be group writeable by cad so people can work there 
j without having to su to chip. Since we don't expect too frequent 
jchanges to proteus it should be no problem having to su, so long as 
■everything is consistently owned by chip. 

Hmmm... I had thought everything was group-writable in proteus, too, but 
perhaps some were missed. I think it's safer for proteus to just do 
everything as chip. 

I thought I heard someone say that chip was not in group cad, so that 
may be part of the problem. 

Tim 
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Sent: 

To: 

Cc: 


Subject: 


From: 


Tim B. Robinson [tbr@gamorra] 
Saturday, NovennberOS, 1994 11:21 PM 
Tom Laidig' 

'geert@aphrodite'; 'hopper@aphrodite'; 'tom@aphrodite' 
Re: permisions problem 


Tom Laidig wrote (on Sat Nov 5) : 

Tim B. Robinson writes: 

I just tried to fire off a make of the snapshot proteus following the 
getbom. It died immediately because of a permission problem trying to 
update ged/mb/mb . lib. I restarted it as chip and it has got past 
there. is everything in that tree owned by chip? We have the euterpe 
snapshot set up to be group writeable by cad so people can work there 
without having to su to chip. Since we don't expect too frequent 
changes to proteus it should be no problem having to su, so long as 
everything is consistently owned by chip. 

Hmmm. . . I had thought everything was group -writable in proteus, too, but 
perhaps some were missed. I think it's safer for proteus to just do 
everything as chip. 

I thought I heard someone say that chip was not in group cad, so that may be part of the 
problem . 


Tim 
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To: 


From: 


Sent: 


Tom Laidig [tom@clio] 

Saturday. November 05, 1994 11:23 PM 

Tim B. Robinson' 


Co: 'tom@gamonra' 
Subject: Re: leafmold 

Tim B, Robinson writes: 


ITom Laidig wrote (on Sat Nov 5): 

I Tim B. Robinson writes: 

I |Tom Laidig wrote (on Sat Nov 5): 

I I Tim B. Robinson writes: 

I I I 

I I I Looks like there is more trouble. I think I started up the re-run as 

I I jme rather than chip and there are probably permissions problems all 

j I jover the place. Please look at the log files in the leafmold 

I I Idirectory and let me know if I should kill it and restart as chip. 

I I I dont see any evidence that problems were caused by that, but a bunch 

I I of stuff crapped out because of tmp disk messes (on merope, and, to a 

I I lesser extent, on psyche). I suggest killing and restarting because of 

I I this, and then you might as well restart as chip. Also, I'll start a 

j I find looking for files owned by you, which we probably want to delete 

I I before restarting the run as chip. 

j jOK. It's dead. Let me know when to restart. 

j It took a while for the fmd to complete. Here's the list of files you 

I own: 

I ./ged/master.local 

I ./ged/startup, concept 

I ./leafgen/leafinold'Depend 

I ./leafgen/leafinold/tmp.listmarathon 

I ./leafgen/leafinold/tmp.list.merope 

I ./leafgen/leafinold'tmp.list.psyche 

I ./leafgen/leafinold/tmp.list.thalia 

I ./leafgen/leatmold/tmp.list.hepatu 

I ./leafgen/leafinold/tmp.make.out.thaIia 

I ./leafgen/leafinold/tmp.make.out.hepatu 

I ./leafgen/leafmold/tmp.make.out.marathon 

I ./leafgen/leaftnold/tmp.make.out.merope 

j ./leafgen/leafinold/tmp. make.outpsyche 

I ./leafgen/leafinoldyxbmux2dh2s.tmp.eclstats 

I ./verilog/Iibsrc/BOM 

I ./verilog/libsrc/depend 

I ./verilog/libsrc/CVS/Entries 

I ./veriIog/libsrc/tlbmpl3.V 

I ,/verilog/Iibsrc/cpllmacro 1 .V 

I ./verilog/libsrc/pl_euh_macro.V 

I ./verilog/libsrc/pl_eus_macro.V 
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I ./verilog/Hbsrc/Makefile 

I ./verilog/Hbsrc/sc2p3a.V 

I ./verilog/cHb/sc2p3a.v 

I ./verilog/dclib/sc2p3a.v 

I ./verilog/zclib/sc2p3a.v 

I ./verilog/eclib/cpllmacro 1 .edif 

I ./verilog/eclib/tlbmpI3.edif 

I ./verilog/eclib/pl_eus_macro .edif 

I ./verilog/eclib/pl_euh_macro.edif 

I ./verilog/eclib/sc2p3a.edif 

I ./verilog/zblibsrc/logicsim.old 

I ./BOM 

I ./BOM.BAK 

1 ./CVS/Entries 

I ./makerrs 

I ./Makefile 

I So it looks as if you did the getbom as yourself as well as the make. 

I I suggest you remove at least the derived files in this list, and then 

I restart the make. It might be adequate to make these files 

j group-writable, but I'm not sure.,. 

jl didnt do a getbom, you did! At least I havene't done one recently. 

|ril see if I can clean up my mess. 

Oh. Oh? I'm confused again... 

-clio:tom-> 11 /n/auspex/s41/euterpe-snapshot/euterpe/proteus/BOM 

1 -rwxrwxr-x 1 tbr cad 881 Nov 5 1 1:07 /n/auspex/s41/euteTpe-snapshot/euterpe/proteus/BOM* 
-clio:tom-> 


TomL 
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From: tbr 

Sent: Saturday, November 05, 1 994 1 1 :25 PM 

To: Tom Laidig' 

Cc: 'tom@gamorra' 

Subject: Re: leafinold 

Follow Up Flag: Follow up 

Flag Status: Red 


Tom Laidig wrote (on Sat Nov 5); 

Oh. Oh? I'm confused again... 

-clio:tom-> 11 /ii/auspex/s41/euterpe-snapshot/euterpe/proteus/BOM 

1 -rwxrwxr-x 1 tbr cad 881 Nov 5 ll:07/n/auspex/s41/euterpe-snapshot/euterpe/protexis/BOM* 
-ciio:toin-> 

Ah, I understand this one. I had to update the top level Makefile. 
It had not beed released so I did a releasebom of just that file from 
the snapshot. That would have touched the BOM at the top. 

ril probably also own up to updating the BOM in libsrc, but that was 
a while back. 

Tim 
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From: 


tbr 


To: 

Subject: 


Sent: 


Saturday, November 05, 1994 11:27 PM 
'tom'; Vo' 
New problem 


Follow Up Flag: Follow up 
Flag Status: Red 


OK, I have been trying to do a make in the dcell directory to get what 
tom vo needs before I wat for all the leafcell stuff. 

It just died: 

# We don't always get a good gbox from compass . vlsi^box forces a clean gbox 

CHIPROOT=/n/auspex/s23/euterpe-proteus-cp/n/auspex/s23/euterpe-proteus-cp/tools/bin/vlsi^box -v ../compass/vlsi.boo- 

all ttle2ttl.ly 

mv ttle2ttl.ly ../compass/dcell/ttle2ttl.ly 

gmake[l]: *** No rule to make target '_MISSING_LAYOUT_FILE_'. Stop. 
gmake[l]: Leaving directory '/N/auspex/root/s23/euterpe-proteus-cp/dcell' 
gmake: *** [dcells] Eiror 1 


What's going on here? 


Tim 


Exhibit C8 


Page 209 of 598 


From: Fred Obermeier [fwo@pelagon] 

Sent: Saturday, November 05, 1 994 11 : 28 PM 

To: •hopper@boreas'; 'vo@rnerope' 

Cc: •fwo@pelagon'; 'geert@merope'; 'hopper@merope'; 'tbr@merope'; •vanthof@merope' 

Subject: Re: proteus/baseplate 


Hi all, 

Cu5tom_vdd_pad and custom_vdde_pad. ly cells contain the same information and map to the 

same cells on the space transformer. 

During the time calliope was being assembled, Geert agreed that we should only have one 
vdde pad, and we should call it vdde . All custom_vdd_j)ad instances were changed into 
custora_vddejiad instances. When I grep /u/chip/calliope/compass/baseplate/* . ly, I do not 
see any references to custom_vdd_jpad. I also put a note in the Makefile saying that the 
custora_vdd_pad instance will no longer be supported (OLD) . A while ago I removed the 
lines from the Makefile that map this instance. 

We wanted to only have custom_vss_j>ad, custom_vdde_pad, custom_vdda_pad, sofa_vdd_pad and 
sofa_vss_pad cells. 

So, given the current situation, we could either: 

1. Change all custom_vdd_pad to custom_vdde_pad as previously agreed, OR 2. Change 
the proteus/baseplate/Makef ile.base back to support both 
vdd pads. 

Which do we want to do? Either change should be easy, but the second would perpetute the 
confusion over the two different named, but identical vdd pad cells. 

To implement solution 1 requires: 

foreach f (euterpe/compass/layouts) 

sed ' s/custora_vdd_jpad/custora_vddej>ad/g' < $f > $f.tmp 

mv $ f . tmp $ f 

end 

CVS ci -ra "Changed custom_vdd_pad to custom_vdde__pad" 
To implement solution 2 requires: 

cvs diff -r #.## -r #.## Makef ile.base 

vi Makef ile.base # to put back the changes 

Fred. 
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To: 
Cc: 


Sent: 


From: 


Tom Laidig [tom@cliol 

Saturday, November 05, 1994 11:40 PM 

Tim B. Robinson' 

tom@gamorra'; 'vo@gamo[Ta' 


Subject: Re: New problem 

Tim B. Robinson writes: 

I 

I 

|0K, I have been trying to do a make in the dcell directory to get what 
Item vo needs before I wat for all the leafcell stuff, 

I 

|It just died: 

I 

|# We don't always get a good gbox from compass . vlsi_gbox forces a clean gbox 

|CHIPROOT=/n/auspex/s23/euterpe-proteus-cp/n/auspex/s23/euterpe-proteus-cp/tools/bin/vlsi_gbox -v ../compass/vlsi.boo- 
all ttle2ttl.ly 

|mv ttle2ttl.ly ../compass/dcell/ttle2ttl.ly 

|gmake[l]: *** No rule to make target ^_MISSING_LAYOUT_FILE_'. Stop. 
jgmake[l]; Leaving directory '/N/auspex/root/s23/euterpe-proteus-cp/dceir 
jgmake: •** [dcells] Error 1 


jWhat's going on here? 

When layout dependencies are being built and some subcell can't be 
found, the text '_MISSING_LAYOUT_FILE_ missing-cell. ly' is put in the 
dependency file, to make sure that gmake knows it cant build the thing 
that depends on this. In this case, the missing cells are 

-clio:proteus-> grep MISSING dcell/Depend 
_MISSING^LAYOUT_FILE_ XBLDH4S.ly\ 
_MISSING_LAYOUT_FILE_ XBORL2DH4S.Iy \ 
_MISSING_.LAYOUT_FILE_ XBORL2DF4S.ly \ 
_MISSING_LAYOUT_FILE_ XBORL3DF4S.ly \ 
_MISSING_LAYOUT_FILE_ XBLDF4S,ly \ 

-clio:proteus-> 

In this case, all these are used by vdactop, so we can ignore that 
problem. However, some other cells may not have made, since gmake 
ditched out when it encountered the first problem. You can get past 
this by manually running gmake with the -k option to cause it to build 
everything it can. 


TomL 
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Subject: 


To: 


From: 


Sent: 


Cc: 


tbr 

Saturelay, November 05, 1994 11:42 PM 
Tom Laidig' 

'tom@gamorra'; 'vo@gamorra' 
Re: New problem 


Follow Up Flag: Follow up 
Flag Status: Red 

Tom Laidig wrote (on Sat Nov 5): 
Tim B. Robinson writes: 


iOK, I have been trying to do a make in the dcell directory to get what 

jtom vo needs before I wat for all the leafcell stuff. 

I 

|It just died: 

I 

|# We don't always get a good gbox from compass . vlsi_gbox forces a clean gbox 
!CHIPROOT=/n/auspex/s23/euterpe-proteus-cp/n/auspex/s23/euterpe-proteus-cp/tools/bin/vlsi^box 
V ../compassArlsi.boo-all ttle2ttl.ly 
Imv ttle2ttl.Iy ,./compass/dcell/ttIe2ttl.ly 

|gmake[l]: **♦ No rule to make target '_MISSING_LAYOUT_FILE_'. Stop. 
|gTnake[l]; Leaving directory 7N/auspex/root/s23/euterpe-proteus-cp/dceir 
jgmake: *** [dcells] Error 1 


jWhat's going on here? 

When layout dependencies are being built and some subcell can't be 
found, the text ^_MISSING_LAYOUT_FILE_ missing-cell. ly' is put in the 
dependency file, to make sure that gmake knows it can't build the thing 
that depends on this. In this case, the missing cells are 

-clio:fH'oteus-> grep MISSING dcell/Depend 
_MISSING_LAYOUT_FILE_ XBLDH4S.ly\ 
_MISSING_LAYOUT_FILE_ XBORL2DH4S.Iy \ 
_MISSING_LAYOUT_FILE_ XBORL2DF4S.Iy \ 
_MISSING_LAYOUT_FILE_ XBORL3DF4S.ly \ 
_MISSING_LAYOUT_FILE_ XBLDF4S,ly\ 

-clio:proteus-> 

In this case, all these are used by vdactop, so we can ignore that 
problem. However, some other cells may not have made, since gmake 
ditched out when it encountered the first problem. You can get past 
this by manually running gmake with the -k option to cause it to build 
ev^ything it can. 

I want to be able to run the Makefile from the top without error, 
so I don't want to do it that way. I notice that in custom- list 
there are lots of lines commented out corresponding to other calliope 
stuff Looks to me like I could just comment it out there and it will 
treat that one as a dcell rather than a real one. 
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From: Tom Vo [vo@merope] 

Sent: Sunday, November 06, 1994 12:33 AM 

To: 'Fred Obermeier' 

Cc: 'hopper@boreas'; 'fwo@pelagon'; 'geert@merope'; 'hopper@merope': 'tbr@merope'; 

Vanthof@merope' 
Subject: Re: proteus/baseplate 


Fred Obermeier wrote .... 
> 

>Hi all, 
> 

>Custom_vdd_pad. and custoin_vdde_pad . ly cells contain the same 
>information and map to the same cells on the space transformer. 

> 

>During the time calliope was being assembled, Geert agreed that we 
> should only have one vdde pad, and we should call it vdde. All 
>custom_vdd_pad instances were changed into custom_vdde_pad instances. 
>When I grep /u/ chip/calliope/compass/baseplate/* . ly, I do not see any 
^references to 

This won't do . The cell could be hurried in the custom block layout . 

A simple grep in compass/baseplate won't reveal cinything . 

A more reliable way to search is to use vlsimm to query the hierarchy . 


>custom_vdd_pad. I also put a note in the Makefile saying that the 
>custom_vdd_pad instance will no longer be supported (OLD) . A while ago 

>I removed the lines from the Makefile that map this instance. 

The problem is none of this get communicated to the mask designer when they're doing the 
layout . I would even go one step further and remove the cell from the libary once we 
have a clean vlsimm search . 


>We wanted to only have custom_vss_pad, custom_vdde_pad, 
>custom_vdda_jpad, sofa_vddj)ad and Bofa_vss_pad cells. 
> 

>So, given the current situation, we could either: 

> 1. Change all custom_vdd_pad to custora_vdde_pad as previously 

>agreed, OR 2. Change the proteus/baseplate/Makef ile .base back to support both 

> vdd pads. 
> 

>Which do we want to do? Either change should be easy, but the second 
>would perpetute the confusion over the two different named, but 

>identical vdd pad cells. 

> 

>To implement solution 1 requires: 

> f ©reach f (euterpe/ compass /layouts) 

This cell lives in proteus . 

I ' d like to have the layout changed . Could one of you privileged 

cad weenie who can lock/unlock layout cells do it and propagate the change to the proteus 
snapshot . 

> sed • s/custom_vdd_pad/custom_vdde_jpad/g' < $f > $f.tmp 

> rav $f.tmp $f 

> end 

> CVS ci -m "Changed custom_vdd_pad to custom_vdde_pad'' 

>To implement solution 2 requires: 

> CVS diff -r #.## -r #.## Makefile . base 

> vi Makefile .base # to put back the changes 
> 

>Pred. 
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Tom Vo vo@microunity.com (408) 734-8100 
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From: tbe@MicroUnity.com 

Sent: Sunday, November 06, 1 994 1 :29 AM 

To: 'glen' 

Cc: 'pmayer'; 'arya'; 'tbr*; 'woody'; 'albers'; 'jf; 'vijay' 
Subject: prt problems 

We read in the Bandsplit daughtercard today and found that the prt you 
revised Friday night had the correct number of pins, but that the body had 
been increased to 3.4" from the correct 3.15" length, with the extra 
hanging out at the pin 1 end. This does not agree with the markup I gave 
you Friday; can you please rectify? 

Separate issue: Pattie needs the new smart card prt as soon as possible 
Monday; please work with Vijay to obtain the necessary mechanical criteria 
and get to her Monday. Let me know if there are any obstacles. 

Another separate issue: Tim wrote: 

Patricia Mayer wrote (on Thu Nov 3): 

Another part issue that Philip mentioned was a fuducial mark for Caliope 
and Euterpe. ?? 

I think this was worked out for the TAB test board and as far as I 

know we said long ago we would go with the same. Maybe it never made 

it into the prt. I assume glen has a version in PCAD somewhere. 

Tim 

All parts less than (I believe) .050" pitch should have fiducials built 
into the prt. I thought this was addressed in the design guideline. Can 
you please review and ensure that this is the case. Calliope and Euterpe 
do have them in the TAB test board; so should the main pcb. Please get 
them into the prt. 

Thanks, 

-Tom 


Tom Eich j tbe@microunity.com 

MicFoUnity Systems Engineering, Inc.( 
255 Caspian Dr. Sunnyvale, CA 94089 | 
(408)734-8100, (408)734-8136 fax | 

1 
! 
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From: Kurt Wampler [wampler@thoas] 

Sent; Sunday, November 06, 1994 1:38 AM 

To; 'tom@clio' 

Cc: 'cloi@nosferatu'; 'geert@merope'; 'hopper@boreas': 'hopper@merope'; 'lisar@nosferatu'; 

'tbr@merope'; 'tom@nosferatu'; Vanlhof@merope'; 'vo@merope' 
Subject: Re: protection in s41 


Tim Robinson writes: 


>Well, I have to side with torn on this one. We have enough trouble with 
>the complexity of what we are trying to do without planting timebombs. 
>We are totally dependent on Make and doing something that deliberately 
>defeats it is major error. 

I bow to the majority, I have removed all "cp -p" statements from 
makefiles & shell scripts in: 

proteus/clockbias 
proteus/gardswarts/protowart 
proteus/gards/basegen 
proteus/gards/Makefile . chipbase 
euterpe/verilog/bsrc/Makef ile . share 

I do beg to point out, however, that the problem we ran afoul of was 
not a date -based dependency error, but a permission violation that arose 
because group instead of owner permissions were being used. We may r\in 
into similar inconsistencies of implementation in other UNIX utilities if 
we start relying more often on group write permissions. It may be safer 
to do all of these builds as "chip". 

- Kurt 
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Sent: 

To: 

Cc: 


Subject: 


From: 


Tim B. Robinson [tbr@aphrodite] 
Sunday, Novennber 06, 1994 1:49 AM 
'Kurt Wampler' 

'doi@nosferatu'; 'geert@merope'; "hopper@boreas'; 'hopper@merope'; 'lisar@nosferatu'; 
'tom@clio'; 'tom@nosferatu'; 'vanthof@merope'; Vo@merope' 
Re: protection in s41 


Kurt Wampler wrote (on Sat Nov 5) : 
Tim Robinson writes: 


>Well, I have to side with torn on this one. We have enough trouble 
>with the complexity of what we are trying to do without planting 
>timeborabs. We are totally dependent on Make and doing something that 
>deliberately defeats it is major error. 

I bow to the majority. I have removed all "cp -p" statements from 
makefiles & shell scripts in: 


proteus / c lockbias 
proteus/gardswarts/protowart 

proteus/gards/basegen 
proteus/gards/Makef ile . chipbase 
euterpe/verilog/bsrc/Makef ile . share 


Thanks , kurt . 

I do beg to point out, however, that the problem we ran afoul of was 
not a date- based dependency error, but a permission violation that arose 
because group instead of owner permissions were being used. We may run 
into similar inconsistencies of implementation in other UNIX utilities if 
we start relying more often on group write permissions. It may be safer 
to do all of these builds as "chip" . 

I tend to agree . We also have the problem that not everyone has a umask of 2 . In the 
proteus snapshot, I had updated an built a few things as myself, but I have now backed 
those out and rebuilt as chip. 

The euterpe snapshot on the otherhand is mostly owned by non-chip and may be harder to 
clean up. 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Mark Hofmann [hopper@boreas] 
Sunday, November 06, 1994 11 :22 AM 
Tim B. Robinson' 

'wampler@thoas'; 'doi@nosferatu'; 'geert@merope'; 'hopper@merope'; 'lisar@nosferatu'; 
'tom@clio'; 'tonn@nosferatu'; 'vanthof@merope'; 'vo@merope' 
Re: protection in s41 


Tim B. Robinson writes: 

Kurt Wampler wrote (on Sat Nov 5) : 
Tim Robinson writes: 


>Well, I have to side with torn on this one. We have enough trouble 
>with the complexity of what we are trying to do without planting 
>timebombs. We are totally dependent on Make and doing something that 
> deliberately defeats it is major error. 

I bow to the majority. I have removed all "cp -p" statements from 
makefiles & shell scripts in: 

proteus/clockbias 
proteus /gardswar t s /prot owart 
pro t eus / gards /bas egen 
proteus/gards/Makef ile . chlpbaae 
euterpe/verilog/bsrc/Makef ile . share 
Thanks , kurt . 

I do beg to point out, however, that the problem we ran afoul of was 

not a date -based dependency error, but a permission violation that arose 
because group instead of owner permissions were being used. We may r\m 
into similar inconsistencies of implementation in 
other UNIX utilities if 

we start relying more often on group write permissions. It may be safer 
to do all of these builds as "chip" . 

I tend to agree. We also have the problem that not everyone has a 
umask of 2 . in the proteus snapshot, I had updated an built a few 
things as myself, but I have now backed those out and rebuilt as 
chip . 

The euterpe snapshot on the otherhand is mostly owned by non-chip 
and may be harder to clean up. 


I'll add my voice here that we should make a rule to do all our builds as chip. 

It is a simple and may avoid more of these permission problems in the future. 

Once the sysadmins make the proper adjustments, everyone should be able to run as "chip" 

for build purposes. Tom- could we build in an "su chip" to the build process? 


Tim 


-hopper 
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From: 


tbr 


Subject: 


Sent: 


To: 


Cc: 


Sunday, November 06, 1994 3:19 PM 
'torn'; 'brinal' 
'hopper' 
Makefile woes 


Follow Up Flag: Follow up 
Flag Status: Red 


There is still a big problem. I now have the snapshot up to the 
latest BOM, so I have the latest Makefiles. 

Starting (riday, the make had run most of the timing numbers, but some 
died becuse of the problems on mercury and merope. 

Then yesterday, I started it over with brian's new Makefile. 
It ran leafinold and built essentially all the cells. Then it went 
back into the timing phase and decided it had to retime everthing. 
According to brian, tiiis was expected, given that leafmold had run. 
I actually interrupted that run after a while because at that point I 
wanted to pick up the latest Makefile stuff from kurt, and get a few 
things I had had to touch into the BOM. 

Now when I restart it, it's decided to re-run leafinold on every damn 
cell (1548 again). What's going on? What are the dependencies involved 
here? Given that I did not let the timing run go to completion 
I can't think it's that that has caused the leafmold reset, because 
presumably it would only have affected a few cells. 

There is a new log in 

s4 1 /euterpe-snapshot/euterpe/proteus/makerrs 

and I cannot see anything unexpected prior to the leafinold run. 
It did however regenerate the Depend file just prior to the leafmold 
build. 


Tim 
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To: 


Subject: 


Sent: 


From: 


tbr 

Sunday, November 06, 1994 3:46 PM 
•torn* 

'vercon error* 


Follow Up Flag: Follow up 
Flag Status: Red 


Any idea what this means? 
** uivokii^ vercon ** 

* * « • «|i 1(1 « Id * * « « « :|e * 4t * * * * * 

Sun Nov 6 13:43:45 PST 19940m30s Om30s 
CARDS VERCON 7.120 ~ Connectivity Verifier 
Copyright (c) 1994 SILVAR-LISCO, All rights reserved. 
Design: leaf Started at: 94/11/06 13:43:45 


VERCON Version 7.1.20 of March 30, 1994 

...reading nets... 

49 Nets Read 
...reading components... 

56 Components Read 
...reading physical types... 

10 Physical Types Read 
...reading logical types... 

**♦* routing progress = 0; no routing information in dff 

Terminated at : 94/1 1/06 13:43:45 
Elapsed CPU time : OHrs 0 Mins 0 Sees 
Elapsed wall clock time : 0 Hrs 0 Mins 0 Sees 

*** gastatus detects error with vercon (see /usr/tmp/leafmold.xbmiixffe9dhl2s) 
gmake[4]: *** [/n/auspex/s23/euteipe-proteus-cp/compass/Iea£'xbmuxfFe9dhl2s.ly] Error 1 
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From: Mark Hofmann [hopper@boreas] 
Sent: Sunday, November 06, 1994 5:03 PM 
To: Tim B. Robinson' 
Cc: Thomas Laidig'; 'Brian Lee' 
Subject: Re: Makefile woes 

Tim B. Robinson writes: 
[snip! 

Now when I restart it, it's decided to re-run leafrnold on every damn 
cell (1548 again). What's going on? What are the dependencies involved 
here? Given that I did not let the timing run go to completion 
I can't think it's that that has caused the leafinold reset, because 
presumably it would only have affected a few cells. 

There is a new log in 

s4 1 /euterpe-snapshot/euteipe/proteus/makerrs 

and I cannot see anything unexpected prior to the leafmold run. 
It did however regenerate the Depend file just prior to the leafmold 
build. 

Tim 

Nor can I, except that the Depend file did not exist. 

Is it re-making all cells or only those that failed to route correctly 

last time? It looks like it's working on muxffe's and HR's. 

-hopper 
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Subject: 


To: 


Sent: 


From: 


Cc: 


tbr 

Sunday, November 06, 1994 5:06 PM 

'Mark Hofmann' 

'Brian Lee'; Thomas Laidig' 

Re: Makefile woes 


Follow Up Flag: Follow up 
Flag Status: Red 

Mark Hofmann wrote (on Sun Nov 6): 
Tim B. Robinson writes: 
[snip] 

Now when I restart it, it's decided to re-run leafinold on every damn 
cell (1548 again). What's going on? What are the dependencies involved 
here? Given that I did not let the timing run go to completion 
I can't think it's that that has caused the leafinold reset, because 
presumably it would only have affected a few cells. 

There is a new log in 

s4 1/euterpe-snapshot/euterpe/proteus/makerrs 

and I cannot see anything unexpected prior to the leafinold run. 
It did however regenerate the Depend file just prior to the leafinold 
build. 


Nor can I, except that the Depend file did not exist. 

Is it re-making all cells or only those that failed to route correctly 

last time? It looks like it's working on muxffe's and HR's. 

It remade 

5 -rw-rw-r~ 1 chip 5066 Nov 6 13:17 xborl3df8s.ly 

bit that's the only one. All the rest it tried failed again. I was 
assuming that since the list files called out all 155 it was going 
to do them all, but it didn't. Now it's back to timing. 


Tim 


Tim 


Exhibit C8 


Page 222 of 598 


From: Geert Rosseel [geert@rhea] 

Sent: Sunday, November 06, 1994 5:29 PM 

To: •geert@rhea' 

Subject: pager log, sender copy 


page from geert to geert: 

pageme gmake geert_euterpegards start :Nov_06_14 : 10 end: Nov_06_15:28 exit 
1 
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From: vant [vanthof@he5tia] 

Sent: Sunday, November 06, 1 994 8:49 PM 

To: Tom Vo' 

Cc: 'hopper@merope'; Vanthof@merope'; 'wampler@merope'; 'geert@merope'; 'tbr@merope'; 
'lisar@merope'; 'tom@merope' 

Subject: Re: euterpe baseplate 

Tom Vo writes: 

> 

> 

>The build is completed . Results are in : 

> 

>/n/auspex/s41/euterpe-snapsbot/euterpe/compass/basep1ate/euterpe.ly . 
>/n/auspex/s4 1 /euteipe-snapshot/euterpe/v»'i1og/bsrc/chip_euterpe-iter.spl vs 

> 

>I looked at our 2 previous error spots , the gtlb cutout and the pU wiring short 
>and they looked OK now . 

> 

>tvo 


Thanks Tom, I'll start up the Ivs and drc runs. 
Dave 


Dave Van't Hof vanthof@microunityxom MicroUnity Systems Engineering, Inc. 

"What rolls down stairs, alone or in pairs, rolls over the neighbor's dog? 

What's great for a snack and fits on your back? It's log, log, log!" 

LOG from BLAMMO! (tm) All kids love Log! #incluce <std_disclaim.h> 
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From: Mark Hofmann [hopper@boreas] 
Sent: Sunday, November 06, 1994 9:28 PM 
To: Vant' 

Cc: Vo@merope'; 'hopper@merope'; 'vanthof@merope'; 'wampler@merope'; 'geert@merope'; 
'tbr@merope': 'lisar@merope'; 'tom@merope' 

Subject: Re: euterpe baseplate 

vant writes: 
> 

Thanks Tom, I'll start up the Ivs and drc runs. 
Dave 

Thanks, Dave 

I see you've got them going, 
-hopper 
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From: Fred Obermeier [fwo@pelagon] 
Sent: Monday, November 07. 1 994 2:33 AM 
To: Vo@merope' 

Cc: 'fwo@pelagon'; 'geert@merope'; 'hopper@boreas'; 'hopper@merope'; 'tbr@merope'; 
Vanthof@merope' 

Subject: Re: proteus/baseplate 

Hi, 

> ... vlsimm to find all uses of custom_vdd jsad .. 

Would it not be sufficient to change all uses of custom_vddj3ad to 

custom_vdde_pad in all /u/chip/{proteus,calliope,euterpe}/compass/*/*.Iy 

files, except for /u/chip/proteus/compass/layouts/custoni_vdd_pwd.ly of 

course? And then cvs remove /u/ch{p/proteus/coinpass/layouts/ciistom_vdd_j>ad.ly? 

Does anyone see anything wrong with this? 

Fred. 
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From: vant [vanthof@hestia] 

Sent: Monday, November 07, 1 994 8:20 AM 

To: 'Fred Obermeier" 

Cc: Vo@merope'; 'fwo@pelagon'; 'geert@merope'; 'hopper@boreas'; 'hopper@merope'; 'tbr@merope'; 
Vanthof@merope' 

Subject: Re: proteus/baseplate 

Fred Obermeier writes: 
> 

>Hi, 

> 

» ... vlsimm to find all uses of custom_vdd_pad 

>WouId it not be sufficient to change all uses of custoni vdd_pad to 

>custom_vdde_pad in all /u/chip/{proteus,calliope,euterpe} /compass/*/*. ly 

>files, except for /u/chip/proteus/compass/layouts/custoni_vdd_pad.ly of 

>course? And flien cvs remove /u/chip/proteus/compassyiayoiUs/custom_vdd_pad.ly? 

>Does anyone see anything wrong with this? 

> 

>Fred. 

> 

I believe this would invalidate the BOM entries for the cells which have 
the custom_vdd__pad as instances. Tim gave a list of things which need to 
be done to keep the BOM consistant. 

Dave 


Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, Inc. 

"What rolls down stairs, alone or in pairs, rolls over the neighbor's dog? 

What's great for a snack and fits on your back? It's log, log, log!" 

LOG from BLAMMO! (tm) All kids love LogI #incluce <std_disclaim.h> 
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From: 
Sent: 
To: 

Subject: 


Alan Corry [agc@aphroclite] 
Monday, November 07, 1994 9:46 AM 
'Geert Rosseel' 

power. tab. local files for euterpe 


I thought I should remind you that when we were working on euterpe a while ago alot of the 
power . tab. local (or genptab.pl) files had "init inst" changed to "inst" because topt at 
the top-level was powering up these outputs since the interconnecting modules were 
missing. Now you've got so much of the top level together you should make sure these drive 
strength settings are changed back to "init inst", if you haven't done so already ? 
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From: Tom Laidig [tom@cliol 

Sent: Monday, November 07, 1 994 1 0:33 AM 

To: 'Tim B. Robinson' 

Subject: Re: 'vercon error" 

Tim B. Robinson writes: 


jAny idea what this means? 

I** invoking vercon ** 

|Sun Nov 6 13:43:45 PST 19940m30s OmSOs 
[CARDS VERCON 7.120 - Connectivity Verifier 
ICopyright (c) 1994 SILVAR-LISCO. All rights reserved. 
IDesign: leaf Started at: 94/11/06 13:43:45 


[VERCON Version 7.1.20 of March 30, 1994 

[...reading nets... 
I 49 Nets Read 
[...reading components... 
[ 56 Components Read 
j... reading physical types... 
I 10 Physical Types Read 
[...reading logical types... 

I **** routing progress = 0; no routing information in dff 

[Terminated at : 94/1 1/06 13:43:45 
[Elapsed CPU time : OHrs OMins 0 Sees 
[Elapsed wall clock time : 0 Hrs 0 Mins 0 Sees 

[*** gastatus detects error with vercon (see /usr/tmp/leafinoId.xbmuxffe9dhl2s) 
|gmake[4]: ***' [/n/auspex/s23/euterpe-proteus-cp/compass/lea£^xbmuxfre9dhl2s.]y] Error 1 


That says it failed on that cell. The current incarnation of leafmold 
runs through a set of different routing strategies, deleting the routing 
from each failing attempt. Thus, if all attempts failed, the final 
vercon run will note no routmg. 


TomL 
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Sent: 


Cc: 


To: 


From: 


Tom Laidig [tom@clio] 

Monday, November 07, 1994 10:48 AM 

Tim B. Robinson' 

'hopper@boreas'; 'brianl@boreas'; 'tom@boreas' 


Subject: Re: Makefile woes 
Tim B. Robinson writes: 


IMarlc Hofinann wrote (on Sun Nov 6): 

I Tim B. Robinson writes: 

I [snip] 

I Now when I restart it, it's decided to re-run leaimold on every damn 

I cell (1 548 again). What's going on? What are the dependencies involved 

I here? Given that I did not let the timing run go to completion 

I I can't think it's that that has caused the leafmold reset, because 

I presumably it would only have affected a few cells. 

I There is a new log in 

I s4 1 /euterpe-snapshot/euterpe/proteus/makerrs 

j and I cannot see anything unexpected prior to the leafmold run. 

I It did however regenerate the Depend file just prior to the leaftnold 

I build. 


j Nor can I, except that the Depend file did not exist. 

I Is it re-making all cells or only those that failed to route correctly 

j last time? It looks like it's working on muxffe's and HR's. 

|It remade 

I 5 -rw-rw-r- 1 chip 5066 Nov 6 13:17 xborl3df8s.ly 

jbit that's the only one. All the rest it tried failed again. I was 
jassuming that since the list files called out all 155 it was going 
|to do them all, but it didn't. Now if s back to timing. 

The Depend file is always remade when you do a 'gmake all'. This one 
cell probably got made because it had failed in all previous tries due 
to some soft error (the most common is not getting the edif license for 
slnet, which I have no good way to detect). 


Tim 


TomL 
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From: Wayne Freitas [wayne@echiclna] 
Sent: Monday, November 07, 1 994 1 1 :20 AM 

To: tbr@echidna'; 'graham@echidna'; 'jt@echidna'; 'mudge@echidna' 

Cc: 'lisar@echidna' 

Subject: Hardware Bring-up meeting 


Hi, I would like to begin having a weelcly hardware bring-up 
meeting for Hestia. The meeting will work in conjunction with the 
software bring-up meeting but focus more on the hardware side of PCA 
planning and requirements, bring-up status/problems, and hardware 
equipment and tool needs. I would like to hold this meeting during 
the beginning of the week, preferably Monday afternoon or Tuesday if 
possible, but I need to know what would be suitable for all of you. 
If you could provide a response with preference, or available time 
slot we can try and get this meeting going. 

If it's not to much of a problem, I would also like to hold the 
meeting a different way. Where an agenda will be posted at least one 
working day (I count working weekends as a workday) before the 
scheduled meeting. If there isn't anything of high enough priority 
to justify a meeting, mail notes on action items or status will be 
posted and the meeting can be cancelled if agreed upon. 

Thanks, 
Wayne 
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From: 
Sent: 
To: 

Subject: 


lisa 

Monday, November 07, 1994 11:37 AM 
'software-checkins-dist' 
gnu-tools/sim/terp cerberus.c 


Update of /p/cvsroot/gnu-tools/sim/terp 

in directory calliope : /N/auspex/root/s6/lisa/src/gnu-tools/sim/terp 

Modified Files: 

Cerberus . c 
Log Message: 

Added some casts to make sure (constant << constant) didn't lose. 
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From: jt@MicroUnity.com 

Sent: Monday, November 07, 1 994 11 :57 AM 

To: 'Wayne Freitas' 

Cc: 'lisar@echidna'; 'tbr@echidna'; 'graham@echidna'; 'mudge@echidna' 
Subject: Re: Hardware Bring-up meeting 

Wayne, 

We should maintain some differentiation from tlie Monday 3pm netlist 
meeting. This can probably be handled by the posted agendas. How about 
Tuesday morning, 10:30 or 11:00? 

-jt 

At 9:19 AM 1 1/7/94 -0800, Wayne Freitas wrote: 

> Hi, I would like to begin having a weekly hardware bring-up 

> meeting for Hestia. The meeting will work in conjunction with the 

> software bring-up meeting but focus more on the hardware side of PCA 

> planning and requirements, bring-up status/problems, and hardware 

> equipment and tool needs. I would like to hold this meeting during 

> the beginning of the week, preferably Monday afternoon or Tuesday if 

> possible, but I need to know what would be suitable for all of you. 

> If you could provide a response with preference, or available time 

> slot we can try and get this meeting going. 

> If it's not to much of a problem, I would also like to hold the 

> meeting a different way. Where an agenda will be posted at least one 

> working day (I count working weekends as a workday) before the 

> scheduled meeting. If there isnt anything of high enough priority 

> to justify a meeting, mail notes on action items or status will be 

> posted and the meeting can be cancelled if agreed upon. 
> 

> Thanks, 

> 

> Wayne 

John Tang Internet: jt@microunity,cora 

MicroUnity Systems Engineering, Inc. 
255 Caspian Dr. Sunnyvale, CA 94089 
(408)734-8100, (408)734-8177 fax 
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From: tbr 

Sent: Monday, November 07, 1994 12:01 PM 

To: Wayne Freitas' 

Cc: 'graham@echiclna'; 'jt@echiclna'; 'lisar@echidna'; 'mudge^echidna* 

Subject: Hardware Bring-up meeting 
Follow Up Flag: Follow up 

Flag Status: Red 


Wayne Freitas wrote (on Mon Nov 7): 


Hi, I would like to begin having a weekly hardware bring-up 
meeting for Hestia. The meeting will work in conjunction with the 
software bring-up meeting but focus more on the hardware side of PC A 
planning and requirements, bring-up status/problems, and hardware 
equipment and tool needs. I would like to hold this meeting during 
the beginning of the week, preferably Monday afternoon or Tuesday if 
possible, but I need to know what would be suitable for all of you. 
If you could provide a response with preference, or available time 
slot we can try and get this meeting going. 

If if s not to much of a problem, I would also like to hold the 
meeting a different way. Where an agenda will be posted at least one 
working day (I count working weekends as a workday) before the 
scheduled meeting. If there isn't anything of high enough priority 
to justify a meeting, mail notes on action items or status will be 
posted and the meeting can be cancelled if agreed upon. 

I suggest Monday 4pm, right after the netlist meeting, but that may be 
a problem for lisar. 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Fred Obermeier [fwo@pelagon] 
Monday, November 07, 1994 1:03 PM 
'tbr@gamorra'; Vo@merope' 

'fwo@pelagon'; •geert@merope'; 'hopper@boreas'; 'vanthof@pelagon' 
Re: proteus/baseplate 


Only four cells use custom_vdd_j3ad : aftop, clrepeat, cr2a, cr3a. 
Euterpe only makes use through: cr2a, and cr3a. 

So, I'm going to change these four layout cells under proteus/ layout s . 
The automatic script under mdunit should do the cvs check-in. 

Could someone do a release bora that really needs this? I'm not sure what else needs to be 
done by others. 


Fred. 


Exhibit C8 


Page 235 of 598 


From: tbr 

Sent: Monday, November 07. 1 994 1:11 PM 

To: 'Fred Obermeier' 

Cc: 'fwo@pelagon'; 'geertOmerope'; 'hopper@boreas'; 'vanthof@pelagon'; 'vo@merope' 

Subject: Re: proteus/baseplate 
Follow Up Flag: Follow up 

Flag Status: Red 


Fred Obermeier wrote (on Mon Nov 7): 

Only four cells use custom_vdd_j)ad: aftop, clrepeat, cr2a, cr3a. 
Euterpe only makes use through: cr2a, and cr3a. 

So, I'm going to change these four layout cells under proteus/Iayouts. 
The automatic script under mdunit should do the cvs check-in. 

Could someone do a release bom that really needs this? I'm not sure 
what else needs to be done by others. 

Are we all happy this does not invalidate the baseplate runs currently 
in progress? 

Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Tim B. Robinson [tbr@aphroclite] 
Monday, November 07, 1994 1:11 PM 
'Fred Obermeier' 

'fwo@pelagon'; 'geert@merope'; 'hopper@boreas'; 'vanthof@pelagon'; 'vo@merope' 
Re: proteus/baseplate 


Fred Obermeier wrote (on Mon Nov 7) : 

Only four cells use custom_vdd_pad: aftop, clrepeat, cr2a, cr3a. 
Euterpe only makes use through: cr2a, and cr3a. 

So, I'm going to change these four layout cells under proteus/ layouts . 
The automatic script under mdunit should do the cvs check- in. 

Could someone do a release bom that really needs this? I'm not sure 
what else needs to be done by others. 

Are we all happy this does not invalidate the baseplate runs currently in progress? 

Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Mark Hofmann [hopper@boreas] 
Monday, November 07, 1994 1:16 PM 
Tim B. Robinson' 

'1wo@pelagon'; 'geert@merope'; Vanthof@pelagon'; 'vo@merope' 
Re: proteus/baseplate 


Tim B. Robinson writes: 

Fred Obermeier wrote (on Mon Nov 7) : 

Only four cells use custom_vdd_j)ad: aftop, clrepeat, cr2a, cr3a, 
Euterpe only makes use through: cr2a, and cr3a. 

So, I'm going to change these four layout cells under proteus / layout s . 
The automatic script under radunit should do the cvs check- in. 

Could someone do a release bora that really needs this? I'm not sure 
what else needs to be done by others. 

Are we all happy this does not invalidate the baseplate runs currently 
in progress? 


I just spoke with tvo and fwo. The current baseplate runs (Fracture and 

DRC) should be consistent and correct since they were run of the old Makefile and used the 
old cell. 

Fred will make these changes and check them in but not release them. 

If the DRC comes back dirty and we need to make changes then we'll batch the pad changes 
in with the other changes and release a new snapshot. 

If the DRC comes back clean, we have the option then of doing a release to add in the 
renamed pads or wait to batch again with other changes. 


Tim 


-hopper 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Tom Vo [vo@merope] 

Monday, November 07, 1994 1:20 PM 

Tim B. Robinson' 

'fwo@pelagon'; •geert@merope'; 'hopper@boreas'; 'vanthof@pelagon' 
Re: proteus/baseplate 


Tim B . Robinson wrote .... 


>Fred Obermeier wrote (on Mon Nov 7) : 
> 

> Only four cells use custotn__vddj>ad: aftop, clrepeat, cr2a, cr3a. 

> Euterpe only makes use through: cr2a, and cr3a. 

> 

> So, I'm going to change these four layout cells under proteus /layouts. 

> The automatic script under mdunit should do the cvs check- in. 

> 

> Could someone do a release bom that really needs this? I'm not sure 

> what else needs to be done by others. 
> 

>Are we all happy this does not invalidate the baseplate runs currently 
>in progress? 


We're all getting cold feet here . In light of the recently discovered fact that the 
snapshot proteus/baseplate/Makef ile . base is one rev behind and what we have in the 
snapshot is really consistent wrt this problem ( a case of 2 wrongs makes right ) , it's 
agreed that we'll perform the fix and check them in , but delay the decision to propagate 
the changes to the snapshot until we see results from the drc run . 


Tom Vo vo@microunity.com (408) 734-8100 


>Tim 


> 


> 
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From: Tom Laidig [tom@clio] 

Sent: Monday. November 07, 1994 3:58 PM 

To: KurtWampler' 

Cc: Thomas Laidig'; 'Daniel Albers'; 'Dave Van't Hof ; 'Marl< Hofmann'; 'Tim B. Robinson'; 'Geert 

Rosseer; Tom Vo' 
Subject: frame updated in euterpe snapshot 


I have just updated the euterpe snapshot to include the frame, I did this by doing a 
getbom in 

eut erpe/pr o t eus / c orapas s / f rame 
added the files: 
p611_allv5 . ly 
p611_allv6 . ly 
p611_etch_llvl . ly 
p611_etch_12vl . ly 
p611_etch_l3vl . ly 
p611_etch_l4vl . ly 
p611_etch_l5vl . ly 
p611„etch_l6vl . ly 
p611_etch_l7vl , ly 
p611_etch_lvl , ly 
p6ll_etch_rlvi . ly 
p611_etchr2vl . ly 
p611_etch_r3vl . ly 
p611_etch_r4vl . ly 
p611_etch_r5vl . ly 
p611_etch__r6vl . ly 
p611_etch_r7vl . ly 
p611_etch_rvl . ly 
p611_etch_vl . ly 
p611_f ocOlOvS . ly 
p611_foc010v6.1y 
p611_foc020v5 .ly 
p611_f oc020v6 . ly 
p611_foc030v5.1y 
p611_foc030v6.1y 
p611_foc040v5 .ly 
p611_f oc040v6 . ly 
p611_f OC050V5 . ly 
p611_foc050v6.1y 
p611_foc060v5.1y 
p611_f OC060v6 . ly 
p611_foc070v5 .ly 
p611_foc070v6.1y 
p611_foc080v5.1y 
p611_f oc080v6 . ly 
p611_foc090v5 .ly 
p611__foc090v6 .ly 
p611_focl00v5 . ly 
p611_focl00v6 .ly 
p611_f ocllOvS . ly 
p611_f OC110V6 . ly 
p611_focl20v5,ly 
p611_focl20v6. ly 
p611_focl3 0v5 . ly 
p611_focl3 0v6. ly 
p611_focl4 0v5.1y 
p611_f OC14 0v6 . ly 
p611_focl50v5.1y 
p611_focl50v6. ly 
p611_focl60v5 . ly 
p611_focl60v6.1y 
p611_focl7 0v5 . ly 
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p611_focl70v6.1y 
p611_focl80v5 .ly 
p611_focl80v6.1y 
p611_focl90v5.1y 
p611_f ocl90v6 . ly 
p611_foc200v5.1y 
p611_foc200v6 .ly 
p611_foG210v5 .ly 
p61l_f OC210V6 . ly 
p611_fOC220v5.1y 
p611_foc220v6.1y 
p611_f ochorzvS . ly 
p611_f ochorzv6 . ly 
p611_f ocvertvS . ly 
p611_f ocvertv6 . ly 

modified the files: 
locked-cells 
proteusf rame . db 
vlsi . cko 
vlsi . log 

cut erpe / compass / layout s 
modified the files: 
fOOOV.ly 


So I think we can start fracturing the frame any time. 


None of the above cells appears in the chip layout hierarchy, so the ongoing chip DRC, 
LVS/ and fracture should be unaffected. 


00000 Ooooo 

( _) (_ ) 

1 ( Tom ) I 
(_) L (_) 
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From: Daniel Albers [albers@boreas] 
Sent: Monday. November 07, 1994 4:05 PM 
To: Tom Laidig' 

Cc: 'wamplerigclio'; 'tom@clio'; 'albers@clio'; Vanthof@clio'; 'hopper@clio'; 'tbr@clio'; 'geert@clio'; 
'vo@clio' 

Subject: Re: frame updated in euterpe snapshot 

> the words of Tom Laidig: 
> 

> I have just updated the euterpe snapshot to include the frame. I did 

> this by doing a getbom in 

> 

> euterpe/proteus/compass/frame 
> 

> 
> 

> So I think we can start fracturing the frame any time. 

> 

> None of the above cells appears in the chip layout hierarchy, so the 

> ongoing chip DRC, LVS, and fracture should be unaffected. 
> 


Everything looks right. 

Thanks, 

Dan 


Daniel Albers albers@microunity.com MicroUnity Systems Engineering, Inc. 
255 Caspian Way, Sunnyvale, CA (408) 734-8100 

It can be made into a monster if we all pull together as a team... 
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From; Mark Hofmann Ihopper@boreas] 
Sent: Monday, November 07, 1994 4:46 PM 
To: Tom Laidig' 

Cc: 'wampIer@clio'; 'tom@clio'; 'albers@clio'; 'vanthof@clio'; 'hopperigclio'; 'tbr@cllo'; 'geert@clio'; 
Vo@clio' 

Subject: Re: frame updated in euterpe snapshot 

Tom Laidig writes: 
I have just updated the euterpe snapshot to include the frame. I did 
this by doing a getbom in 

euterpe/proteus/compass/frame 
added the files: 

[snip] 

modified the files: 
locked-cells 
proteusframe-db 
vlsi.cko 
vlsi.log 

euterpe/compass/layouts 
modified the files: 
fD007.1y 

So I think we can start fracturing the frame any time. 

None of the above cells appears in the chip layout hierarchy, so the 
ongoing chip DRC, LVS, and fi-acture should be unaffected. 

Thanks, Tom 
-hopper 
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From: tbr 

Sent: Monday, November 07, 1994 9:16 PM 

To: Tom Laidig' 

Cc: 'Daniel Albers'; 'Geert Rosseel'; 'Mark Hofmann'; Thomas Laidig'; 'Dave Van't Hof ; Tom 

Vo'; 'Kurt Wampler' 

Subject: frame updated in euterpe snapshot 

Follow Up Flag: Follow up 

Flag Status: Red 


Tom Laidig wrote (on Men Nov 7): 

I have just updated the euterpe snapshot to include the frame. I did 
this by doing a getbom in 

euterpe/proteus/compass/frame 
added the files: 
p611_allv5.ly 
p611_allv6.ly 
p611_etch_llvl.ly 
p6n_etch_12vl.Iy 
p611_etch_13vl.ly 
p61 l_etch_I4vl .ly 
p611_etch_15vl.ly 
p6Il_etch_16vl.ly 
p611_etch_17vl.ly 
p611_etch_lvl.ly 
p611_etch_rlvl.ly 
p611_etch_r2vl.ly 
p613etch_r3vl,ly 
p6 1 1 _etch_r4v 1 . ly 
p61 l_etch_r5vLly 
p61 l_etch_r6vl.]y 
p61 letchrVvl.ly 
p611 etch rvl.ly 
p61 l etch vl.ly 
p611_foc010v5.ly 
p61I_foc010v6.1y 
p611_foc020v5.1y 
p611_foc020v6.1y 
p61 1_foc030v5.1y 
p611_foc030v6.1y 
p6n_foc040v5.1y 
p6ll_foc040v6.1y 
p611_foc050v5.1y 
p6n_foc050v6.1y 
p611_foc060v5,ly 
p61 l_foc060v6Jy 
p6il_foc070v5.]y 
p611_foc070v6.1y 
p611_foc080v5.1y 
p611_foc080v6.Iy 
p61 1_foc090v5.1y 
p611_foc090v6.1y 
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p611_focl00v5.1y 
p611_focl00v6.1y 
p611_focll0v5.1y 
p611_focll0v6.1y 
p611_focl20v5.1y 
p61l_focl20v6.1y 
p611_focl30v5.1y 
p611_focl30v6.1y 
p6Il_focl40v5.1y 
p611_focl40v6.1y 
p611_focl50v5.ly 
p611_focl50v6.ly 
p611_focl60v5.Iy 
p611_focl60v6.Iy 
p611_focl70v5.1y 
p611_focl70v6.ly 
p6Il_focl80v5.1y 
p611_focl80v6.ly 
p611_focl90v5.1y 
p611_focl90v6.1y 
p61 1_foc200v5.1y 
p61l_foc200v6.1y 
p611_foc210v5.1y 
p611_foc210v6.1y 
p6n_foc220v5.1y 
p611_foc220v6.1y 
p61 l_fochorzv5.1y 
p6I l_fochorzv6Jy 
p611_focvertv5.1y 
p611_focvertv6.]y 

modified the files: 
locked-cells 
proteusframe.db 
vlsixko 
visi.Iog 

euterpe/compass/layouts 
modified the files: 
fOOOT.ly 

So I think we can start fracturing the frame any time. 

None of the above cells appears in the chip layout hierarchy, so the 
ongoing chip DRC, LVS, and fracture should be unaffected. 

As soon as the current proteus build completes (est tomorrow evening) 
we should look at bringing over the latest BOM from the top level 
and re-running the Make. I assume this will not have any effect on 
the fram stuff. 

Tim 
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From: Tim B. Robinson [tbr@aphrodite] 

Sent: Monday, November 07, 1994 9:16 PM 

To: 'Tom Laidig' 

Cc: 'Daniel Albers'; 'Geert Rosseel'; 'Mark Hofmann'; 'Thomas Laidig'; 'Dave Van't Hof ; Tom Vo'; 

'Kurt Wampler' 

Subject: frame updated in euterpe snapsliot 


Tom Laidig wrote (on Mon Nov 7) : 

I have just updated the euterpe snapshot to include the frame. I did 
this by doing a getbotn in 

euterpe/proteus/corapass/ frame 
added the files: 
p611_allv5 . ly 
p611_allv6.1y 
p611_etch_llvl . ly 
p611_etch_l2vl . ly 
p611_etch_l3vl . ly 
p611_etch_l4vl . ly 
p6ll_etch_15vl . ly 
p611_etch_16vl . ly 
p611_etch_17vl . ly 
p611_etch_lvl . ly 
p611_etch_rlvl . ly 
p611_etch_r2vl . ly 
p611_etch_r3vl . ly 
p611_etch_r4vl . ly 
p611_etch_r5vl . ly 
p611_etch_r6vl . ly 
p6ll_etch_r7vl . ly 
p611_etch_rvl , ly 
p611_etch_vl , ly 
p611_f ocOlOvS . ly 
p611_foc010v6.1y 
p611_foc020v5.1y 
p611_foc020v6. ly 
p611_f oc03 Ov5 . ly 
p611_foc03 0v6.1y 
p611_foc040v5.1y 
p611_f oc040v6 . ly 
p611_foc050v5.1y 
p611_foc050v6.1y 
p611_foc060v5.1y 
p611_f oc060v6 . ly 
p611_f OC070V5 . ly 
p611_foc070v6.1y 
p611_f oc080v5 . ly 
p611_f oc080v6 . ly 
p611_foc090v5 .ly 
p611_f oc090v6 . ly 
p611_focl00v5.1y 
p611_focl00v6.1y 
p611_f ocllOvS . ly 
p611_focll0v6 . ly 
p611_focl20v5 , ly 
p611_f ocl20v6 . ly 
p611_focl3 0v5.1y 
p611__focl3 0v6 . ly 
p611_focl40v5 . ly 
p611_focl40v6 . ly 
p611_focl50v5.1y 
p611_f ocl50v6 . ly 
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p611_focl60v5.1y 
p611_focl60v6.1y 
p611_f ocl70v5 . ly 
p611_focl70v6.1y 
p611_focl80v5.1y 
p611_focl80v6.1y 
p611_focl90v5.1y 
p611_focl90v6, ly 
p611_foc200v5.1y 
p611_foc200v6 . ly 
p611_foc210v5 . ly 
p611_f OC210V6 . ly 
p611_foc220v5 .ly 
p611_f oc220v6 . ly 
p611_f ochorzvs . ly 
p611_f ochorzv6 . ly 
p611_f ocvertvB . ly 
p611_f ocvertv6 . ly 

modified the files: 
locked- cells 
proteus frame . db 
vlsi . cko 
vlsi . log 

euterpe/compass/ layouts 
modified the files: 
f0007.1y 

So I think we can start fracturing the frame any time. 

None of the above cells appears in the chip layout hierarchy, so the 
ongoing chip DRC, LVS, and fracture should be unaffected. 

As soon as the current proteus build completes (est tomorrow evening) we should look at 
bringing over the latest BOM from the top level 

and re-running the Make. I assume this will not have any effect on 
the fram stuff. 

Tim 
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Sent: 

To: 

Cc: 


From: 


tbr 

Tuesday, November 08, 1994 12:05 AM 


'doi' 
'lisar' 


Subject: 


releasebom 


Follow Up Flag: Follow up 
Flag Status: Red 

I got the following on releasing a BOM which I don't recall seeing 
before. 

Does it indicate some sort of error? 

Note: Forced Release of BOM in euterpe/verilog/bsrc Version 172,0 


Tim 
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From: 


tbr 


Subject: 


To: 


Sent: 


Cc: 


Tuesday, November 08, 1994 1:05 AM 
'geert' 

'brianl'; 'woody'; 'dickson'; 'hopper'; 'vo' 
snapshot status 


Follow Up Flag: Follow up 
Flag Status: Red 

I have updated the euterpe snapshot to BOM 172.0, which includes 
everything except the most recent change to nb. 

The following placements are incomplete: 

at, ice, ife, iq, uu 

(uu was not complete before), nb was also updated, but per hopper's 
latest placement message, I expect this to converge OK. It is running 


now. 


The only other logic change was in Cerberus. 


Tim 
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Subject: 


From: 


Sent: 

To: 

Cc: 


Tim B. Robinson [tbr@aphroclite] 
Tuesday, November 08, 1994 1:05 AM 
'geert@aphrodite' 

'brianl@aphrodite'; 'woody@aphrodite'; 'dlcKson@aphrodlte'; 'hopper@aplirodjte'; 

'vo@aphrodite' 

snapshot status 


I have updated the euterpe snapshot to BOM 172.0, which includes everything except the 
most recent change to nb. 

The following placements are incomplete: 

at, ice, ife, iq, uu 

(uu was not complete before), nb was also updated, but per hopper's latest placement 
message, I e3q}ect this to converge OK. It is running now. 

The only other logic change was in Cerberus. 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Jay Tomllnson [woody@luckboy] 
Tuesday, November 08, 1994 9:13 AM 
'euterpe@luckboy' 
'bobm@luckboy' 

FINAL Decision: instruction cache tag bit change 


This decision is now final . 
jay 


Jay Tomlinsozi wrote (on Thu Nov 3) : 

The current micro-arch doc defines the bits of the instruction cache tag as 
follows : 


I propose changing the location of the Execution Access field to allow the 
hardware to use bit 0 as a valid bit (bit 0 of the data cache tag is the defined 
as the dirty-bit) . This change would speed up the l-cache miss processing by 
allowing the hardware to invalidate the tag entry without having to write the 
entire entry. This change will also simplify the euterpe hardware. The tag array 
has a write-enable for this bit. 

My proposal for the new bit definitions is: 


bit 
7 


meaning 

Caching control, exception 3 if set 
Detail access, exception 2 if set 
ignored by hardware 

Execution access, causes exception 1 if > privilege 


6 


5. .2 

1. .0 


level 


bit 
7 


meaning 

Caching control, exception 3 if set 
Detail access, exception 2 if set 
ignored by hardware 

Execution access, causes exception 1 if > privilege 


5. .4 
3 . .2 


level 


1 
0 


ignored by hardware 
valid 


This change will become final at 11:59PM Monday, Nov 7, 1994. 
Objections should be sent out immediately and can be reviewed 
Friday /Monday . 


Jay 
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From: Derek Iverson [clo)@clemeter] 

Sent: Tuesday. November 08, 1 994 10:17 AM 

To: Tim B. Robinson' 

Cc: 'doi ©aphrodite'; 'lisar@aphrodite' 

Subject: releasebom 

Tim B. Robinson writes: 
> 

> I got the following on releasing a BOM which I don't recall seeing 

> before. 

> Does it indicate some sort of error? 

> 

>Note: Forced Release of BOM in euterpe/verilog/bsrc Version 172.0 

1 added this message to remind people that use the -F option that 
even though the output from releasebom said the BOM was unchanged 
at the top level, it was forced as a release. 

I, of course, had a bug in that I ^always"^ printed it. sigh. 

fixed. 

doi 
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From: 
Sent: 
To: 

Subject: 


lisa 

Tuesday, November 08, 1994 12:29 PM 
'software-checkins-d ist' 
gnu-tools/sim/terp cycles, h 


Update of /p/cvsroot/gnu-tools/sira/terp 

In directory calliope : /N/auspex/root/s6/lisa/src/gnu-tools/sira/terp 

Modified Files: 
cycles. h 
Log Message: 

Added ZSTALL to those needing "adjustment". 
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From: 
Sent: 
To: 

Subject: 


lisa 

Tuesday. November 08, 1994 12:30 PM 
'software-checkins-dist" 
gnu-tools/sim/terp events. c 


update of /p/cvsroot /gnu-tools/sim/terp 

In directory calliope: /N/auspex/ root /s6/lisa/src/gnu-tools/sim/terp 

Modified Files: 
events . c 
Log Message : 

Clear last_regs and last_thread in do_exception() the current instruction should not 
get a register trace. 
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From: tbr 

Sent: Tuesday, November 08, 1994 12:53 PM 

To: 'Derek Iverson' 

Cc: 'doi@aphrodite'; 'lisar@aphrodite' 

Subject: releasebom 

Follow Up Flag: Follow up 

Flag Status: Red 


Derek Iverson wrote (on Tue Nov 8): 

Tim B. Robinson writes: 

> 

> 1 got tiie following on releasing a BOM which I don't recall seeing 

> before. 

> Does it indicate some sort of error? 
> 

> Note: Forced Release of BOM in euterpe/verilog/bsrc Version 172.0 

I added this message to remind people that use the -F option that 
even though the output from releasebom said the BOM was unchanged 
at the top level, it was forced as a release. 

I, of course, had a bug in that I ^always*** printed it. sigh. 

fixed. 
Thanks. 
Tim 
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From: Mark Hofmann Ihopper@tomato] 
Sent: Tuesday, November 08, 1994 1 :30 PM 
To: 'vent' 

Cc: 'hopper@hestia'; 'tom@hestia'; 'vanthof@hestia'; 'tbr@hestia' 
Subject: Re: euterpe and cache drc tests 

vant writes: 

The upper drc's on euterpe came back clean. It took 40 hours instead of the 
normal 64 hours (on a spare 10). Not a dramatic improvement, but still 
significant. The 40 hour run was with 1 dracula and 1 vlsimm thread. The 
dracula thread took about 19 hours and the vlsimm thread took the 40. I've 
now started up another test with the vlsimm thread split into two processes 
on trex. I'm hoping the two processes will finish in under 30 hours, but 
it's hard to guage at this time, once these finish, we can look at splitting 
the flow up into more parallel segments to try and balance out the 19 hour 
dracula run with multiple vlsimm runs. 

The lower drc's are much more dracula limited and splitting these up into 
more than 2 parts is probably not as profitable. 

Vve also started an all layer drc run on the cache using 1 dracula license 
and 4 vlsimm processes. 

I've got both processes on all 4 dracula machines busy with these tests and 
real drc's. 

Confusing, but if this all works, then it means we could really split up the 
drc's across as many as 7 processors or more with some tuning. 

I'll keep ya posted. 

Thanks, 
Dave 

Neat. (But now I've lost my gards machine [ :-( ]. Perhaps it's time to 
look into more sparcIO hardware. ) 

-hopper 


Exhibit C8 


Page 256 of 598 


From: 
Sent: 
To: 

Subject: 


lisa 

Tuesday, November 08, 1 994 6:68 PM 
'software-checkins-dlst' 
gnu-tools/sim/terp cycies.c 


l^date of /p/cvsr cot /gnu -tools/ Sim /terp 

In directory calliope : /N/auspex/root/s6/lisa/src/gnu-tools/sini/terp 

Modified Files: 
cycles . c 
Log Message: 

Change BRANCHX latency to 2 (which is time from bback issue to rl available) . 
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From: 
Sent: 

To: 

Subject: 


lisa 

Tuesday, November 08, 1994 7:00 PM 
'software-checklns-dist' 
gnu-tools/sim/terp execute, c 


Update of /p/cvsroot /gnu-tools/sim/terp 

In directory calliope: /N/auspex/root/s6/lisa/src/gnu-tools/sim/terp 

Modified Files: 
execute . c 
Log Message: 

A bback takes 6 major cycles from its issue to issue of next insn. 
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From: 
Sent: 
To: 

Subject: 


llsa 

Tuesday, November 08, 1994 7:01 PM 
'software-checkins-dlst' 
gnu-tools/slm/terp events.c 


Update of /p/cvsroot/gnu- tools/aim/ teip 

In directory calliope: /N/auspex/root/s6/lisa/src/gnu-tools/siin/terp 

Modified Files: 
events . c 
Log Message: 

In do_interrupt ( ) , do a register trace for the setting of rl. 
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From: 
Sent: 
To: 

Subject: 


lisa 

Tuesday, November 08, 1994 7:02 PM 
'software-checkins-disf 
gnu-tools/sim/terp decode.c 


update of /p/cvsroot/gnu-tools/sim/terp 

In directory calliope: /N/auspex/root/s6/lisa/src/gnu-tools/sim/terp 

Modified Files: 
decode , c 
Log Message : 

Make bback show rl as a destination so register traces and dependencies are properly- 
handled . 
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From: vant [vanthof@hestia} 
Sent: Tuesday, November 08, 1 994 8:10 PM 
To: 'Mark Hofmann'; Thomas Laidig' 
Co: 'Dave Van't Hof ; Tim B. Robinson' 
Subject: euterpe and cache drc tests 


The upper drc's on euterpe came back clean. It took 40 hours instead of the 
normal 64 hours (on a spare 10). Not a dramatic improvement, but still 
significant. The 40 hour run was with 1 dracula and 1 vlsimm thread. The 
dracula thread took about 19 hours and the vlshnm thread took the 40. I've 
now started up another test with the vlsimm thread split into two processes 
on trex. I'm hoping the two processes will finish in under 30 hours, but 
it's hard to guage at this time, once these finish, we can look at splitting 
the flow up into more parallel segments to try and balance out the 19 hour 
dracula run with multiple vlsimm runs. 

The lower drc's are much more dracula limited and splitting these up into 
more than 2 parts is probably not as profitable. 

I've also started an all layer drc run on the cache using 1 dracula license 
and 4 vlsinun processes. 

rve got both processes on all 4 dracula machines busy with these tests and 
real drc's. 

Confusing, but if this all works, then it means we could really split up the 
drc*s across as many as 7 processors or more with some tuning. 

ril keep ya posted. 

Thanks, 
Dave 

Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, Inc. 

"What rolls down stairs, alone or in pairs, rolls over the neighbor's dog? 

Whafs great for a snack and fits on your back? It*s log, log, logl" 

LOG from BLAMMO! (tm) All kids love Log! #incluce <std_disclaim.h> 
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From: vant [vanthof@hestia] 

Sent: Tuesday, November 08, 1994 10:29 PM 

To: 'Mark Hofmann' 

Cc: Thomas Laidig'; "Tim B. Robinson'; 'Dave Van't Hof 
Subject: Re: euterpe and cache drc tests 

Maik Hofmann writes: 

> 

>Neat. (But now I've lost my gards machine [ :-( ]. Perhaps it's time to 
>]ook into more spare 10 hardware. ) 

> 

>-hopper 

> 

rm hoping the job on tomato will be done early this morning, so you can 
have it back tomorrow :-) 

These studies will pay off in the future as it will help in optimizing 
the run times to keep the drc runs short, one thing iVe already seen from 
running the cache is the upper checks take longer than the lower because 
of the pedestals. It might be really beneficial to split the metals checks 
into 3 or 4 threads instead of the current 2. 

Thanks, 
Dave 


Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, Inc. 

"What rolls down stairs, alone or in pairs, rolls over the neighbor's dog? 

What's great for a snack and fits on your back? It's log, log, log!" 

LOG from BLAMMO! (tm) All kids love Log! #incluce <std_disclaim.h> 
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To: 


Subject: 


Sent: 


From: 


tbr 

Wednesday, November 09, 1994 12:18 AM 
'Mark Hofmann' 

Re: euterpe and cache drc tests 


Follow lip Flag: Follow up 
Flag Status: Red 

Mark Hofmann wrote (on Tue Nov 8): 

vant writes: 

The upper drc's on euterpe came back clean. It took 40 hours instead of the 
nonnal 64 hours (on a spare 10). Not a dramatic improvement, but still 
significant. The 40 hour run was with 1 dracula and 1 visimm thread. The 
dracula thread took about 19 hours and the visimm thread took the 40. I've 
now started up another test with the visimm thread split into two processes 
on trex. I'm hoping the two processes will finish in under 30 hours, but 
it's hard to guage at this time, once these finish, we can look at splitting 
the flow up into more parallel segments to try and balance out the 19 hour 
dracula run with multiple visimm runs. 

The lower drc's are much more dracula limited and splitting these up into 
more than 2 parts is probably not as profitable. 

Pve also started an all layer drc run on the cache using 1 dracula license 
and 4 visimm processes. 

Tve got both processes on all 4 dracula machines busy with these tests and 
real drc's. 

Confusing, but if this all works, then it means we could really split up the 
drc's across as many as 7 processors or more with some tuning. 

I'll keep y a posted. 


Neat (But now I've lost my gards machine [:-(]. Perhaps it's time to 
look into more sparclO hardware. ) 

Better start some serious budget planning for 95. We are aheady way 


We have ordered an evaluation of a 90MHz dual spare module (eta 
4 weeks) and according to don there is expected to be an announcement 
from sun in the next week or so of 1 OOMHz modules. (The ones we have 
now are 50MHz I think). So there is a possibility of a significant 
speedup at modest cost. 


Thanks, 
Dave 


over. 


Tim 
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To: 


Sent: 


From: 


Mark Hofmann [hopper@tomato] 
Wednesday, November 09, 1994 12:37 AM 
Tim B. Robinson' 


Co: 'hopper@aphrodjte'; 'doi@aphrodite' 
Subject: Re: verilog 

Tim B. Robinson writes: 

Scanning library directory "/n/auspex/sl5/tbr/eiiterpe/proteus/verilog/clib" 

/bin/sh: 14141 Bus error 

gmake: *** [bsim] Error 138 

tbr@gamorra ~/euterpe/verilog/bsrc 472 % cname 

da-verilog-grx 


Which version are we getting by defeult? Fve not seen core dumps 
before. 

we should be back to getting the verilog 1 .7 version (which we've run for about 
a year) by default. 

Dickson had several core dumps from gmake on gammora. We have traced this 

to panics and hard errors on Gamorra's disks. It looks like you may 

have been on gamorra at the time, could you re-tiy from another machine? 


-thanks, 
hopper 
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From: Mark Hofmann [hopper@tomato] 

Sent: Wednesday, November 09, 1994 12:42 AM 

To: Tim B. Robinson' 

Subject: Re: euterpe and cache drc tests 

Tim B. Robinson writes: 

Better start some serious budget planning for 95. We are already way 
over. 

We have ordered an evaluation of a 90MHz dual spare module (eta 
4 weeks) and according to don there is expected to be an announcement 
fh)m sun in the next week or so of lOOMHz modules. (The ones we have 
now are SOMHz I think). So there is a possibility of a significant 
speedup at modest cost. 

Okay. 

I don't have any idea what the '95 budget looks like. 

I think we should plan on needing more hardware, especially as we will have 
multiple chips in design, verification, and fracture/tapeout. 

I would approach this by saying that we will be able to offset our 
hardware purchases by some amount as we reduce our software (CAD) costs 
by moving to our own home-grown tools. 

Should we meet to discuss this further? 

-hopper 


Exhibit C8 


Page 265 of 598 


From: 


tbr 


To: 


Sent: 


Subject: 


NAfednesday. November 09, 1994 7:58 AM 

'hopper'; 'doi' 

verilog 


Follow Up Flag: Follow up 
Flag Status: Red 

Scanning library directoiy '7n/auspex/sl5/tbr/euterpe/proteus/verilog/clib" 

/bin/sh : 14141 Bus error 

gmake: **♦ [bsim] Error 138 

tbr@gamorra ~/euterpe/verilog/bsrc 472 % cname 

da-verilog-grx 


Which version are we getting by default? I've not seen core dumps 

before. 


Tim 
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From: 


tbr 

Wednesday, November 09, 1994 10:21 AM 
'Mark Hofmann* 

'doi@aphrodlte'; 'sysadminhopper@aphrodite' 
Re: verilog 


Sent: 

To: 

Cc: 


Subject: 


Follow Up Flag: Follow up 
Flag Status: Red 

Marie Hofmann wrote (on Wed Nov 9): 

Tim B. Robinson writes: 

Scanning library directory "/n/auspex/sl5/tbr/euterpe/proteus/verilog/cIib" 

/bin/sh: 14141 Bus error 

gmake: *** [bsim] Error 138 

thr@gamorra ~/euterpe/verilog/bsrc 472 % cname 

da-verilog-grx 


Which version are we getting by default? I've not seen core dumps 
before. 

we should be back to getting the verilog 1 .7 version (which we've run for about 
a year) by defeult 

Dickson had several core dumps from gmake on gammora. We have traced this 

to panics and hard errors on Gamorra's disks. It looks like you may 

have been on gamorra at the time, could you re-tiy from another machine? 

OK, will do. 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


B. P. Wong [bpw@frodo] 

Wednesday, November 09, 1994 11:30 AM 

'mnemo@frodo' 

'bpw@frodo' 

Re: FINAL DECISION: PCI driver 


> IMMINENT DECISION: 
> 

> We have decided to use the IDT FCT buffer P.N. IDT74FCT164 24 5T as the 

> PCI driver. We will then use the current euterpe I/O buffer as the 

> mnemo I/O buffer even for the PCI bus. The PCI bus will be buffered 

> by the IDT74FCT16424 5T. 
> 

> Date for Final DECISION is set at Wednesday, Nov 9, 1994 at 8:00am if 

> there is no objection to this proposal. 


Since there was no explicit objections the decision as stated is considered final and will 
be implemented using the IDT74FCT164245T or an equivalent. 


> 


> bpw 


> 


bpw 
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From: Manoj Puri [purl@MicroUnity.com] 

Sent: Wednesday, November 09, 1994 12:34 PM 

To: 'abbott (Curtis Abbott)' 

Subject: Re: gnu-tools/sim/terp/calliope cabJe-in.c 


> Newsgroups: muse . checkins . software 

> From: puri®MicroUnity , com (Manoj Puri) 

> Distribution: local 

> Organization: posters R us 

> Date: 4 Nov 94 23:55:06 GMT 
> 

> Update of /p/sof tware- src/gnu- tools/sim/terp/calliope 

> In directory 

mp : /N/auspex/root/sl9/puri/root/gnu-tools/sim/terp/calliope 
> 

> Modified Files: 

> cable - in. c 

> Log Message : 

> This update includes a fix for IQ- imbalance problems and also 
includes henry's timing code. 

> 

> Given that this is linked into the calliope simulator, I don't 

> understand why it would include Henry's timing code. Can you explain? 
> 

> - Curtis 


what I have is the "dsplib" version of his timing code, I don't think he has any 
terp version ready. 

Manoj 
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From: 
Sent: 
To: 

Subject: 


abbott 

Wednesday. November 09, 1994 12:59 PM 
'Manoj Puri' 

Re: gnu-tools/sim/terp/calliope cable-in. c 


You don't seem to have understood my question. Timing code is simulating software that 
will be running on Euterpe in a Hestia system. Code in the . . . /gnu- 
tcols/sim/terp/calliope is simulating hardware that's part of Calliope. 

I think I figured out the answer to my question: you're using cable- in. c to run your 
simulations in addition to the hardware simulation. I see you've got a very non-standard 
setup for this, Makefile-wise, but I guess I see what's going on. 


- Curtis 
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From: lisa 

Sent: Wednesday, November 09, 1994 3:19 PM 

To; 'software-checkins-dlst' 

Subject: gnu-tools/sim/terp events.c execloop,c execute.c run.c simgdb.c stats.c stats.h 

stbgateway.c terp.h uv.c uv.h 


Update of /p/cvsroot/gnu-tools/sim/terp 

In directory calliope : /N/auspex/root/s6/lisa/src/gnu-tools/sim/terp 
Modified Files: 

events.c execloop.c execute.c run.c simgdb.c stats.c stats.h 
stbgateway.c terp.h uv.c uv.h 

Log Message: 

Removed all move-engine stuff. 
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From: lisa 

Sent: Wednesday, November 09, 1994 3:24 PM 

To: 'Scott Furman' 

Subject: Re: gnu-tools/sim/terp events.c execloop.c execute.c mn.c simgdb.c stats.c stats.h 


Don't cry. It's all in res... ;-) 
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From: vant [vanthof@hestia] 

Sent: Wednesday. November 09, 1994 4:63 PM 

To: 'Mark Hofmann'; 'Thomas Laidig' 

Cc: 'Dave Vant Hof ; 'Tim B. Robinson' 

Subject: euterpe upper drc's finished again 


the latest test of euterpe upper drc's finished, and it only took 21 hours 
versus 64 for a single dracula run. The two vtsimm threads were using 
trex and the dracula thread was on medusa, with the latest revision to the 
drc flow, the run time should be around 20 hours for this version of euterpe. 
As we add more routing metal, tiie runtimes will take longer, but not veiy 
much. We might optimizitically get a iullchip metals drc in 24 hours using 
3 processors (2 of which are sgi). 

I think I'll start up some tests on the lower layers to try and get those 
running a lot faster. 

Dave 

Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, Inc. 

"What rolls down stairs, alone or in pairs, rolls over the neighbor's dog? 

What's great for a snack and fits on your back? It's log, log, log!" 

LOG from BLAMMO! (tm) All kids love Log! #incluce <std_disclaim.h> 
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Cc: 

Subject: 


From: 
Sent: 
To: 


Derek Iverson [doi@demeter] 
Wednesday, November 09, 1994 6:50 PM 

'gmo@demeter'; 'guarino@demeter'; 'wayne@demeter'; 'jeffm@demeter'; 
'sandeep@demeter'; 'gregg@demeter'; •doi@demeter* 
'hestia@demeter'; 'iisar@demeter' 
Software Bring-up Meeting - November 9, 1994 


Software Bringup Meeting 


November 9, 1994 


Next Meeting: 


November 16 at 10:00 am. 


Review of the bring-up section of the euterpe schedule. 
Review of CBI related issues. 


Attendees: jeffm, guarino, gmo, wayne, doi, sandeep, gregg 


Review of Action Items 


Item: How are we supposed to track individual compontents in 

verification? 

Who : mudge 

Status : complete 

Johnny talked to Trancy and JT and they were planning 
on putting a combination wafer/ lot number on each of the 
tab devices. It was noted that this would not uniquely 

identify any particular chip. 

Johnny has more follow-up to do in regards to this item 
but it is outside the scope of this meeting. 

Item: Are there plans to allow tab devices to be replaced on boards? 

who : mudge 

Status : complete 

Johnny has said that there has been talk of allowing 
tab devices to be removed from boards and another device 
siibstituted. 

There is also more follow-up work on this topic but 
it is outside the scope of this meeting. 

Item: Define Parallel interface 
Who: wayne, gmo, sandeep 
Status : complete 

Description has been added to the CBI document . 

Item: Implement parallel port device drivers for sun and sgi. 
Who : sandeep , doi 
Status: on hold 

Sandeep discovered that the parallel port on the sgi machines 
is not documented (which would prevent any local development 
of a device driver) and also does not support and form of 
interrupt mechanism (which we assumed in talking about how 
we would implement this workstation portion of the parallel 
CBI interface) . 
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There is more discussion on this item later in the minutes. 

Item: Define the boot state for standalone tests 
Who: gmo, jeffm 
Status : done 

We have now added a new action item. 

Item: Write up a plan for virtual devices and their interaction with 
gdb. 

who : gmo 

Status: in progress 

Item: Build scripting/ui capabilities above gdb for regression tests. 
Who : doi 

Status: no progress 

Item: Create a separate tool for loading flashROM 
Who : wayne 
Status : done 

The prom programmer company has supplied the algorithm and 

it has been tested satisfactorily. 

Item: Implement remote gdb with the software simulator 

Who : sandeep 

Status: in progress 

Sandeep is almost done. He is able to debug the ukernel 

and is now working on downloading and debugging applications. 

Item: Get durations for items on the schedule for hestia function test 
Who : doi 

Status: in progress 

Some dates have been supplied but more are needed. Derek will 
send out mail with the missing dates identified. 

Item: Add the verification group's test control document to the 

bring -up plan. 
Who: jeffra 
Status : done 

Item: identify our brinp-up tools and maike sure we have plans for how 

we will debug them. 
Who : doi , et . al . 
Status: in progress 

Item: Develop plan for testing real-time software before the analog 

parts of calliope work. 
Who : gregg 

Status: in progress (plan by 11/16) 

Item: Determine which pins can be software controlled on each of the 

sun port. 
Who : doi 

Status: in progress (done by 11/16) 

Item: Ask Craig if an abort invalidates the byte in transit or the 
entire 

packet . 
Who : wayne 
Status : done 

Item: Create performance test plan 
Who: jeffm, guarino 
Status: no progress 
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Item: Add Unix- like tests to software acceptance tests. 
Who : guarino 

Status: slight progress 


New Action items 


Item: Write the boot code 
Who : gmo 
Status : new 

Item: Add gdb stub to boot code 

Who : sandeep 

Status: start on 11/14 

Item: Virtual device support 
Who : gmo , sandeep 
Status: start on 11/14 

This will actually start after gdb boot stub has begun. 
Sandeep estimated a finish time of 12/19. 

Item : CerbROM support from terp . 
Who: gmo, sandeep 
Status : new 


General Discussion 


There is going to be a seperate meeting to discuss the hardware portion of the bring- up 
process. This will be initiated by wayne and the first meeting is scheduled for monday 
(11/14) at 4:00pm. 

Jeff mentioned that he could make use of cerbROM support in terp right away. This 
resulted in a new action seen above. 

There was some discussion about alternatives to using the parallel port to talk to the CBI 
hardware in light of the news that our planned implemention for the sgi machines may not 
be possible. 

We brain-stormed some possible configurations: 

Explanation of abbreviations: 

gcbi gpib interface on CBI. 
ecbi ethernet interface on CBI 

mcbi micro- controller imbedded in CBI to handle the 
unspecified interface. 

1, [workstation] <ethemet> [ethernet/gpib] <:gpib> [gcbi] <cerberus> [hestia] 

[ translator ] 

pros: Any hestia box is accessible from euiy workstation (just 

like having a hestia on everyones desk without actually 

having a hestia on everyones desk) . 

Ethernet/gpib translator already exists. 

Gpib and parallel definition are very similar, 
cons: Expense of translator (-$300) 

2 . [workstation] <gpib> [gcbi] <cerberus> (hestia] 

pros: Gpib and parallel definition are very similar, 
cons: Cost of gpib card for workstation. 
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will driver for gpib card support the functionality 

that we want? 

3. [workstation] <private ethernet> [ecbi] <cerberus> [hestia] 

pros: ? (gmo had some, but I forgot) 

cons: Need second ethernet card for workstation. 

Development of a simple cerberus/ethernet 

translator. 

4 . [workstation] <unknown media> [rocbi] <cerberus> hestia 

•pros: support any media interface 
cons : development time 


There needs to more discussion on what we need to do to support the CBI interface in light 
of the pandora plans. 

Do we need a parallel CBI interface or is the serial 
interface sufficient? Serial interface currently implies 
that the clock is controlled by the workstation only. 

Is there any need for a low- cost interface for hestia 
(i.e. something other than pandora} outside the company? 

Do we think we have different requirements now for an 
interface to hestia that we had previously? 

I think we need to have a gathering of tbr, lisar, gmo, guarino, wayne, . . . 

to further hash out what our requirments and direction shouild be on the CBI issue. 
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From: Wayne Freitas [wayne@echidna] 

Sent: Wednesday, November 09. 1994 9:32 PM 

To: 'tbr@echldna' 

Cc: 'ljsar@echidna'; 'gap@echidna'; 'mouss@echjdna' 
Subject: AST NDA (the saga) 

Tim; 

cc Grant and John; 

Tim, as you know I would like to use the AST box to help us in the 
bring-up and testing of Hestia by providing a standalone interface that 
connected directly to Hermes. Currently the AST box has a 500MB 
internal bus but only supports a 200MB digital interface. When I spoke 
to the AST engineers a while back they were thinking about upgrading 
the interface to 500MB but not until 3rd Q of 95. 1 inquired about 
designing an interface for us that works around the 300MB range, and 
there response was positve, and what seemed of relative ease. Since 
then I have been trying to get a NDA signed, but have run into a 
multitude of problem with AST signing our NDA. So the question I have 
is, how much data constitutes signing an NDA, can we have them sign our 
NDA under some form of understanding on our part. I have outline two 
approaches as to what I view as necessary. 

1) (minimum) 

Data acquision and stimulus rate of 350MHz. (requires us to design interface circuit) 

2) (perfered) 

Vol, Vil, Voh, Vih, lol, lil, loh, lil, min-max elk duty cycle, elk to data set-up and hold time. 
Clock requirement ( divide by 2 for stimulus), pin capacitance, data overshoot 
and undershoot max, data and elk signals differential. 

As indicted before, I have always viewed the AST as a necessary 
bring-up tool to help exerise Calliope/Euterpe in a standalone mode 
for board and system level tests. We can still use the AST without 
the modification, but to connect to Hermes would require a level 
translator interface, and the PLL would have to be bypassed which 
defeats the purpose. Any help would be greatly appreciated. 

Thanks, 

Wayne 

> 

>I had a telephone conversation with AST (Applied Signal) and they 
>infonned me that they could not execute an NDA with us and give us the 
>assurance that any AST employee would be bound by that agreement. It 
>seems that they do not execute NDA's with their people and as a result 
>none of their employees would be bound by our agreement - After 
>discussing this with Lois, I put Applied Signal on an internal mission 
>to find a compromise, if any. 
> 

>So, what do they have a need to know? Can we proceed without an NDA? 

> 

>Grant 
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From: Wayne Freitas [wayne@echidna] 

Sent: Wednesday, November 09, 1994 9:35 PM 

To: 'tbr@echidna' 

Subject: swag dates for Euterpe and Calliope 


Tim I've been updating the bring-up schedule and could really use a better guess 
than mine of when Calliope and Euterpe might be available. Would you care to 
provide a swag? 

Thanks, 
Wayne 
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From: Eric Murray [ericm@MicroUnity.com] 
Sont: Thursday, November 10, 1994 10:01 AM 
To: 'sysadm@MicroUnity.com' 
Subject: disk usage report 

For directories over 100 megs: 
user's info: 


briani 

1403 

hopper 

1231 

chip 

1028 

dickson 

907 

fwo 

889 

craig 

874 

geert 

847 

jsw 

684 

tbr 

659 

rozen 

575 

gmo 

570 

vanthof 

559 

brendan 

479 

sandeep 

472 

vijay 

466 

h 

464 

rocky 

449 

qua 

436 

brian 

417 

wampler 

370 

ken 

337 

tbe 

326 

veena 

304 

khp 

291 

age 

281 

fur 

280 

doi 

271 

torn 

268 

hchu 

258 

ras 

239 

fung 

219 

cox 

213 

iimura 

211 

peter 

206 

bill 

205 

rich 

195 

hessam 

192 

jeffin 

191 

lisar 

189 

haim 

189 

mws 

186 

al 

181 

biliz 

174 

ericm 

172 

Vandyke 

171 

solo 

169 

bpw 

154 

gregg 

151 

guarino 

151 
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lisa 

146 

randy 

142 

win oiird 

140 

woody 

138 


136 

jeff 

135 

dane 

132 


130 

tomho 

126 

albers 

125 

hayss 

125 

kgk 

123 

warren 

123 

fambro 

119 

yves 

117 

chuck 

117 

mikew 

115 

ong 

112 

paulb 

102 


packages info: 
chip-euterpe-bui 1 2017 
calliope 1579 
news 1441 
euterpe-verify 1011 
chip-archive 868 
orchis_snap 811 
chip-proteus 795 
calliope>disk2 730 
cadence 639 
soft-src 639 
losf-build 637 
ptolemy 605 
archives 586 
sun 568 
cadence, hp 552 
soft 489 
calliope 1-fractur 487 
chip-calliope 484 
chip-terpsichore 475 
sgi 377 
xl Ir5_ken_p26 329 
castor-retry 325 
bosf-build 323 
chip-archive-terp 3 1 8 
calliope-overflow 297 
bigtmp 295 
mips-4.52 282 
osf 260 
chip-archive-mnem 259 
X11r4 228 
bsd 222 
cadence_doc 221 
synopsys 216 
cadence_doc_9402 215 
budtool_db 190 
budtool 180 
Motif 177 
mechanica 1 64 


Exhibit C8 


Page 281 of 598 


sgi5 152 

ucberl 147 

vlsi.v8r4_2 145 

proe_tmp 138 

ftp 134 

khoros 1 34 

proe_13.0 134 
calliope-verify 132 

iiniura.be 128 

gnu 125 

bsd43 115 

frame-4.0.3 114 

svr4 114 

Xllr5 111 

lib 110 

iimura-cross 106 

chip-mdunit 105 

motif 1.2 101 


machine user megs package megs total megs max capacity % used 

auspex 19828 18612 38441 62240 61% 

rama 3667 2392 6059 9428 64% 

Aea 211 1599 1810 2484 72% 

gaea 5 1827 1833 1780 102% 

cronus 626 2216 2842 6208 45% 

auspex rama rhea gaea cronus: 

24337 26646 50985 82140 62% 
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From: Charlie Root [root@MicroUnity.com] 
Sent: Thursday, November 1 0, 1 994 11 :33 AM 
To: 'sysadmin@gaea' 

Subject: BudTool Backup Report 48 Successful. 5 volumes used, 3809520 KB written. 

09:33:11>== ^=========:==.===_===_===:==.=========^==__ 

09:33: 1 1> Backup Statistics: 

09:3 3 : 1 1 > Media server : stackerO 

09:33:1 1> Start Time : Wed Nov 9 22:00:39 1994 

09:33:1 1> Time completed : Thu Nov 10 09:33:1 1 1994 

09:33: 1 1> Elapsed time : 1 1 :32:32 

09:33:1 1> Total data written :3809520 KB 

09:33: 11> Overall performance : 91 KB/sec 

09:33:1 1> Volumes used :5 

09:33:1 1> Write Retries : 6510 

09:33:1 1> Number of Requests : 48 

09:33:1 1> Successful Requests : 48 

09:33: 11> Status Summary : No errors 

09:33:1 1> 


Complete log follows. 

22:00: 16> Copyright (c) 1990-1994 by Delta Microsystems goserver BudTool 4.2.0 
22:00: 1 6> goserver process id = 12523 

22:00:23> ===~=— ===_===_==_==_==_==_== 
22:00:23> Start packet received. Requests: 48 

22:00:24> =======—======== —===—== — -.-^ 

22:00:24> Checking Volume Modes/Labels for validity 
22:00:24> Reading the volume's label. 
22:00:36> The current volume has label of 'incr_3' 
22:00:37> Checking Volume Modes/Labels done 

22:00:38> ■ ■ ^ ^ = 

22:00:39> Time started: Wed Nov 9 22:00:39 1994 

22:00:39> Reading the volume's label. 

22:01 :05> The current volume has label of Mncr_3' 

22:01:08> 

22:0 1 :08> Open Volume : incr_3 

22:0 1:09> Current # files: 131 

22:01 :09> Remaining space : 4581417 KB 

22:01:10> 

22:01 :10> Request Identification (#1): 
22:01 :10> Requestor : root@auspexO 
22:01:10> Id : adOa 
22:0 1 : 1 0> Path : auspexO:/ 
22:01 :10> Type : dump 
22:0 1 : 1 0> File History : Maintained 
22:01 : 1 1> Positioning to append to tape 
22:03:58> Volume label : incr 3 
22:03:58> File number : 132 
22:03:58> - — 

22:04: 15> DUMP: Date of this level 4 dump: Wed Nov 9 22:04:10 1994 
22:04: 15> DUMP: Date of last level 3 dump: Tue Nov 8 22:03:53 1994 
22:04: 1 6> DUMP: Dumping /dev/radOa (/) to standard output 
22:04: 17> DUMP: mapping (Pass I) [regular files] 
22:04: 18> DUMP: mapping (Pass II) [directories] 
22:04:20> DUMP: mapping (Pass U) [directories] 
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22:04:21> DUMP: estimated 3014 blocks (1 .47MB) 

22:04:2 1> DUMP: dumping (Pass III) [directories] 

22:04:2 1> DUMP: dumping (Pass IV) [regular files] 

22:04:47> DUMP: level 4 dump on Wed Nov 9 22:04:10 1994 

22:04:47> DUMP: 3008 blocks (1.47MB) 

22:04:48> DUMP: DUMP IS DONE 

22:04:48> Backup command completed successfully. 

22:04:55> 

22:04:55> Request Statistics: 
22:04:55> Data written : 1560 KB 
22:04:55> Elapsed time : 00:03:45 
22:04:55> Status : Successful 
22:04:55> Performance :6KB/sec 
22:04:55> Peak rate :0KB/sec 
22:04:5 5> Write Retries: -6 

22:04:55> 

22:04;56> 

22:04:56> Request Identification (#2): 
22:04:56> Requestor : root@auspexO 
22:04:56> Id : adOe 
22:04:5 6> Path : auspexO:/export 
22:04:56> Type : dump 
22:04:5 6> File History : Maintained 
22:04:5 7> Volume label : incr_3 
22:04:57> File number : 133 
22:04:57> 

22:05:10> DUMP: Date of this level 4 dump: Wed Nov 9 22:05:06 1994 

22:05:10> DUMP: Date of last level 3 dump: Tue Nov 8 22:04:43 1994 

22:05: 1 1> DUMP: Dumping /dev/radOe (/export) to standard output 

22:05: 1 2> DUMP: mapping (Pass I) [regular files] 

22:05:44> DUMP: mapping (Pass II) [directories] 

22:05:46> DUMP: mapping (Pass II) [directories] 

22:05:47> DUMP: mapping (Pass II) [directories] 

22:05:48> DUMP: estimated 72766 blocks (35.53MB) 

22:05:48> DUMP: dumping (Pass III) [directories] 

22;05:49> DUMP: dumping (Pass IV) [regular files] 

22:08: 1 1> DUMP: level 4 dump on Wed Nov 9 22:05:06 1994 

22:08:1 1> DUMP: 72812 blocks (35.55MB) 

22:08: 1 1> DUMP: DUMP IS DONE 

22:08: 12> Backup command completed successfully. 

22:08: 16> 

22:08: 16> Request Statistics: 
22:08: 16> Data written : 36420 KB 
22:08: 1 6> Elapsed time : 00:03 :20 
22:08:16> Status : Successful 
22:08:16> Performance : 182 KB/sec 
22:08: 16> Peak rate : 352 KB/sec 
22:08: 17> Write Retries: 98 

22:08: 1 7> 

22:08: 17> 

22:08: 1 7> Request Identification (#3): 
22:08: 17> Requestor : root@auspexO 
22:08: 17> Id : adOf 
22:08: 17> Path : auspexO:/var 
22:08: 17> Type : dump 
22:08: 1 7> File History : Maintained 
22:08: 18> Volume label : incr_3 
22:08:I8> File number : 134 
22:08: 18> 

22:08:31> DUMP: Date of this level 4 dump: Wed Nov 9 22:08:26 1994 
22:08:3 1> DUMP: Date of last level 3 dump: Tue Nov 8 22:07:20 1994 
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22 : 08 : 3 1 > DUMP: Dumping /dev/radOf (/var) to standard output 
22:08:33> DUMP: mapping (Pass I) [regular files] 
22:08:44> DUMP: mapping (Pass II) [directories] 
22:08:45> DUMP: mapping (Pass II) [directories] 
22:08:46> DUMP: estimated 19782 blocks (9.66MB) 
22:08:46> DUMP: dumping (Pass III) [directories] 
22:08:47> DUMP: dumping (Pass IV) [regular files] 
22:09:37> DUMP: level 4 dump on Wed Nov 9 22:08:26 1994 
22:09:37> DUMP: 19838 blocks (9.69MB) 
22:09:37> DUMP: DUMP IS DONE 
22:09:38> Backup command completed successfully. 

22:09:4l> 

22:09:4 ]> Request Statistics: 
22:09:4 1> Data written : 9960 KB 
22:09:41> Elapsed time : 00:01:24 
22:09:4 1> Status : Successfiil 
22:09:4 1> Performance : 118 KB/sec 
22:09:4 1> Peak rate : 96 KB/sec 
22:09:42> Write Retries: 13 

22:09:42> 

22:09:43> - 


22:09:43> Request Identification (#4): 
22:09;43> Requestor : root@auspexO 
22:09:43> Id : adOg 
22:09:43> Path : auspexO:/usr 
22:09:43> Type : dump 
22:09:43> File Histoiy : Maintained 
22:09:44> Volume label : incr_3 
22:09:44> File number : 135 
22:09:44> 

22;09:57> DUMP: Date of this level 4 dump: Wed Nov 9 22:09:53 1994 

22:09:57> DUMP: Date of last level 3 dump: Tue Nov 8 22:08:31 1994 

22:09:59> DUMP: Dumping /dev/radOg (/usr) to standard output 

22:09:59> DUMP: mapping (Pass I) [regular files] 

22: 1 0: 1 1 > DUMP: mapping (Pass U) [directories] 

22: 1 0: 1 9> DUMP: mapping (Pass II) [directories] 

22:10:21> DUMP: estimated 180 blocks (90KB) 

22:10:22> DUMP: dumping (Pass III) [directories] 

22: 10:22> DUMP: dumping (Pass IV) [regular files] 

22:10:28> DUMP: level 4 dump on Wed Nov 9 22:09:53 1994 

22: 1 0:28> DUMP: 244 blocks ( 1 22KB) 

22: 1 0:28> DUMP: DUMP IS DONE 

22: 10:29> Backup command completed successfully. 

22:10:34> 

22:10:34> Request Statistics: 
22: 1 0:34> Data written : 1 80 KB 
22:10:34> Elapsed time : 00:00:51 
22:10:34> Status : Successful 
22:10:34> Performance : 3 KB/sec 
22:10:34> Peak rate :0 KB/sec 

22:10:35> 

22:10:35> 


22:10:35> Request Identification (#5): 
22 : 1 0: 3 5> Requestor : root@auspex( 
22:10:35> Id :vpl00 
22:10:35> Path : auspex0:/s27 
22:1 0:3 5> Type : dump 
22: 1 0: 3 5> File History : Maintained 
22: 1 0:36> Volume label : incr_3 
22:10:36> Filenumber : 136 
22:10:36> 
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22:10:49> DUMP: Date of this level 8 dump: Wed Nov 9 22:10:45 1994 

22:10:49> DUMP: Date of last level 3 dump: Tue Nov 8 22:09:19 1994 

22: 1 0:50> DUMP: Dumping /dev/rvp 1 00 (/s27) to standard output 

22: 1 0:50> DUMP: mapping (Pass I) [regular files] 

22: 1 2:46> DUMP: mapping (Pass 11) [directories] 

22: 14: ] 6> DUMP: estimated 274 blocks (1 37KB) 

22: 1 4: 1 6> DUMP : dumping (Pass III) [directories] 

22: 1 7:05> DUMP: dumping (Pass IV) [regular files] 

22:17:10> DUMP: level 8 dump on Wed Nov 9 22:10:45 1994 

22:17:10> DUMP: 18234 blocks (8.90MB) 

22: 1 7: 1 0> DUMP: DUMP IS DONE 

22:1 7:3 7> Backup command completed successfiilly. 

22:17:42> 

22:I7:42> Request Statistics: 
22:17:42> Data written : 9120 KB 
22:17:42> Elapsed time : 00:07:07 
22:17:42> Status : Successful 
22 : 1 7 :42> Performance : 2 1 KB/sec 
22:17:42> Peak rate : 17 KB/sec 

22:17:45> 

22:17:46>- 


22:17:46> Request Identification (#6): 
22:17:46> Requestor : root@auspexO 
22:17:46> Id : vplOl 
22:I7:46> Path : auspex0:/s28 
22:I7:46> Type : dump 
22: 17:46> File History : Maintained 
22:17:47> Volume label : incr_3 
22:17:47> File number : 137 
22:17:47> 

22: 18:02> DUMP: Date of this level 8 dump: Wed Nov 9 22: 1 7:56 1 994 

22:18:02> DUMP: Date of last level 3 dump: Tue Nov 8 22:1 5:43 1994 

22: 1 8:02> DUMP: Dumping /dev/rvp 1 0 1 (/s28) to standard output 

22: 18:03> DUMP: mapping (Pass I) [regular files] 

22:20:4 1> DUMP: mapping (Pass II) [directories] 

22:22:00> DUMP: estimated 274 blocks (137KB) 

22:22:0 1> DUMP: dumping (Pass III) [directories] 

22:23 :24> DUMP: dumping (Pass IV) [regular files] 

22:23 :29> DUMP: level 8 dump on Wed Nov 9 22:17:56 1994 

22:23:29> DUMP: 8248 blocks (4.03MB) 

22:23:29> DUMP: DUMP IS DONE 

22:23 :44> Backup command completed successfiilly. 

22:23:50> 

22:23 :50> Request Statistics: 
22:23 :50> Data written : 4140 KB 
22:23 :50> Elapsed time : 00:06:04 
22:23 :50> Status : Successful 
22:23:50> Performance : II KB/sec 
22:23:50> Peak rate :0 KB/sec 

22:23:50> 

22:23:51> 

22:23:5 1> Request Identification (#7): 
22:23:5 1> Requestor : root@auspexO 
22:23:5l> Id : vpl02 
22:23:5 1> Path : auspex0:/s29 
22:23:5 1> Type : dump 
22:23 :5 1 > File History : Maintained 
22:23 :52> Volume label : incr 3 
22:23:52> File number : 138 
22:23 :52> 

22:24:07> DUMP: Date of this level 8 dump: Wed Nov 9 22:24:02 1994 
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22:24:07> DUMP: Date of last level 3 dump: Tue Nov 8 22:30:39 1994 

22:24:07> DUMP: Dumping /dev/rvpl02 (/s29) to standard output 

22:24:08> DUMP: mapping (Pass I) [regular files] 

22:26:04> DUMP: mapping (Pass 11) [directories] 

22:26:3 1> DUMP: mapping (Pass II) [directories] 

22:26:46> DUMP: mapping (Pass II) [directories] 

22:26:53> DUMP: estimated 635124 blocks (3I0.12MB) 

22:26:53> 

22:26:53> WARNING 

22:26: 3 3> Insufficient space remaining on media. 
22:26:53> 

22:26:53> The backup utility's estimate for the size of the backup 
22:26: 5 3> exceeds the remaining space left on the volume. 

22:26:53> 

22:26: 53> Estimated Space Remaining 
22:26:53> Size (KB) on Volume (KB) 

22:26:53> 

22:26:53> 317440 211073 

22:26:53> 

22:26; 5 3> The backup will be restarted on the next volume. 

22:26:53> 

22:26:53> 

22:26:53> WARNING ~ 

22:26: 5 3> Command killed by operator. The backup 
22:26: 53> is in the process of being killed. Please 
22:26:53> be patient. 

22:26:53> 

22:26: 54> DUMP: Write error on standard output 

22:26:54> DUMP: Cannot recover 

22:26:54> DUMP: The ENTIRE dump is aborted. 

22:26:56> Disposing of file history scratch file 

22:27:34> Writing a trailer to end of data 

22:3 1 :33> Reading the volume's label. 

22:3 1 :36> The cuirent vohune has label of 'incr_4' 

22:31:37> 

22:3 1 :37> Open Volume : incrjl 

22:31:38> Current # files : 87 

22:31;38> Remaining space : 4581775 KB 

22:31:39> 

22:3 1:39> Request Identification (#7): 
22:31:39> Requestor : root@auspexO 
22:31:39> Id : vpl02 
22:31:39> Path : auspex0:/s29 
22:31:39> Type : dump 
22 :3 1 :3 9> File History : Maintained 
22:3 1 :40> Positioning to append to tape 
22:34: 32> Volume label : iticr_4 
22:34: 32> File number : 88 
22:34:32> 

22:34:45> DUMP: Date of this level 8 dump: Wed Nov 9 22:34:41 1994 
22:34:45> DUMP: Date of last level 3 dump: Tue Nov 8 22:30:39 1994 
22:34:46> DUMP: Dumping /dev/rvp 1 02 (/s29) to standard output 
22:34:47> DUMP: mapping (Pass I) [regular files] 
22:37:24> DUMP: mapping (Pass 11) [directories] 
22:37:5 1> DUMP: mapping (Pass II) [directories] 
22:38:06> DUMP: mapping (Pass II) [directories] 
22:38:13> DUMP: estimated 704896 blocks (344.19MB) 

22:38: 13> 

22:38:13> WARNING 

22:38: 13> Insufficient space remaining on media. 
22:38: 13> 
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22:38: 13> The backup utility's estimate for the size of the backup 
22:38: 13> exceeds the remaining space left on the volume. 
22:38: 13> 

22:38: 1 3> Estimated Space Remaining 
22:38: 1 3> Size (KB) on Volume (KB) 

22:38:13> 

22:38:13> 352256 43777 
22:38: 13> 

22:38: 13> The backup will be restarted on the next volume. 

22:38: 13> 

22*38* 13> 

22:38:13> WARNING 

22:38; 1 3> Command killed by operator. The backup 
22:38: 13> is in the process of being killed. Please 
22:38: 13> be patient 

22:38:13> 

22 : 3 8: 1 4> DUMP: Write error on standard output 

22:38: 14> DUMP: Cannot recover 

22:38: 14> DUMP: The ENTIRE dump is aborted. 

22:38: 15> Disposing of file history scratch file 

22:3 8; 54> Writing a trailer to end of data 

22:42:58> Reading the volume's label. 

22:43 :02> The current volume has label of 'incr_5' 

22:43:03> 

22 :43 :03> Open Volume : incr_5 

22:43:04> Current # files : 73 

22:43 :04> Remaining space : 4581529 KB 

22:43:05> 

22:43:05> Request Identification (#7): 
22:43:05> Requestor : root@auspexO 
22:43:05> Id : vpl02 
22:43 :05> Path : auspex0:/s29 
22:43:05> Type : dump 
22:43 :05> File History : Maintained 
22:43:06> Positioning to append to tape 
22:45:50> Volume label : incr_5 
22:45:50> File number : 74 
22:45:50> 

22:46:04> DUMP: Date of this level 8 dump: Wed Nov 9 22:45:59 1994 
22:46:04> DUMP: Date of last level 3 dump: Tue Nov 8 22:30:39 1994 
22:46:04> DUMP: Dumping /dev/rvpl02 (/s29) to standard output 
22:46:05> DUMP: mapping (Pass I) [regular files] 
22:48:02> DUMP: mapping (Pass II) [directories] 
22:48:29> DUMP: mapping (Pass IT) [durectories] 
22:48:46> DUMP: mapping (Pass II) [dbectories] 
22:48:53> DUMP: estimated 704896 blocks (344. 19MB) 

22:48:53> 

22:48:53> WARNING 

22:48:53> Insufficient space remaining on media. 
22:48:53> 

22:48:53> The backup utility's estimate for the size of the backup 
22:48:53> exceeds the remaining space left on the volume. 
22:48:53> 

22:48:53> Estimated Space Remaining 
22:48:53> Size (KB) on Volume (KB) 

22:48:53> - — 

22;48:53> 352256 294385 
22:48:53> 

22:48:53> The backup will be restarted on the next volume. 

22:48:53> 

22:48:53> 
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22:48:53> WARNING 

22:48:5 3> Command killed by operator. The backup 
22:48:53> is in the process of being killed. Please 
22:48:53> be patient. 

22:48:53> 

22:48:54> DUMP: Write error on standard output 
22:48:54> DUMP: Cannot recover 
22:48 :54> DUMP: The ENTIRE dump is aborted. 
22;48:55> Disposing of file history scratch file 
22:49:33> Writing a trailer to end of data 
22:53:3 1> Reading the volume's label. 
22:53:34> The current volume has label of 'incr_6' 

22:53:36> 

22:53 :36> Open Volume : incr_6 

22:53:36> Current # files: 65 

22:53 :36> Remaining space : 4581661 KB 

22:53:38> 

22:53 :38> Request Identification (#7): 
22:53:38> Requestor : root@auspexO 
22:53:38> Id : vpl02 
22:53 :38> Path : auspex0:/s29 
22:53:38> Type : dump 
22:53 :38> File History : Maintained 
22:53:38> Positioning to append to tape 
22:56:24> Volume label : incr_6 
22:56:24> File number : 66 
22:56:24> 

22:56:37> DUMP: Date of this level 8 dump: Wed Nov 9 22:56:32 1994 
22:56:37> DUMP: Date of last level 3 dump: Tue Nov 8 22:30:39 1994 
22:56:3 8> DUMP: Dumping /dev/rvpl02 (/s29) to standard output 
22:56:38> DUMP; mapping (Pass I) [regular files] 
22:5 8:3 7> DUMP: mapping (Pass 11) [directories] 
22:59:04> DUMP: mapping (Pass II) [directories] 
22:59: 19> DUMP: mapping (Pass II) [directories] 
22:59:27> DUMP: estimated 704896 blocks (344.19MB) 

22:59:27> 

22:59:27> WARNING 

22:59:27> Insufficient space remaining on media. 
22:59:27> 

22:59:27> The backup utility's estimate for the size of the backup 
22:59:27> exceeds the remaining space left on the volume. 

22:59:27> 

22:59:27> Estimated Space Remaining 
22:59:27> Size (KB) on Volume (KB) 

22:59:27> 

22:59:27> 352256 257009 
22:59:27> 

22:59:27> The backup will be restarted on the next volume. 

22:59:27> 

22:59:27> 

22:59:27> WARNING 

22:59;27> Command killed by operator. The backup 
22:59:27> is in the process of being killed. Please 
22:59:27> be patient. 

22:59:27> 

22:59:27> DUMP: Write error on standard output 
22:59:27> DUMP: Cannot recover 
22:59:28> DUMP: The ENTIRE dump is aborted. 
22:59:29> Disposing of file history scratch file 
23:00:12> Writing a trailer to end of data 
23:04:12> Reading the volume's label. 
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23 :04: 1 5> The current volume has label of Mncr_7' 

23:04:16> 

23:04:16> Open Vohime : incr_7 

23:04:17> Current # files : 1 

23:04:17> Remaining space : 4582696 KB 

23:04:18> 

23:04:18> Request Identification (#7): 
23 :04: 1 8> Requestor : root@auspexO 
23:04: 18> Id :vpl02 
23:04:1 8> Path : auspex0:/s29 
23:04:18> Type : dump 
23 :04: 1 8> File History : Maintained 
23:04: 1 9> Positioning to append to tape 
23:04:50> Volume label : incr_7 
23 ,04:5 0> File number :2 
23:04:50> 

23:05:05> DUMP: Date of this level 8 dump: Wed Nov 9 23:05:00 1994 

23:05:05> DUMP: Date of last level 3 dump: Tue Nov 8 22:30:39 1994 

23 :05 :06> DUMP : Dumping /dev/rvp 1 02 (/s29) to standard ouQ5ut 

23 :05:06> DUMP: mapping (Pass I) [regular files] 

23:07:05> DUMP: mapping (Pass II) [directories] 

23:07:33> DUMP: mapping (Pass 11) [directories] 

23:07:48> DUMP: mapping (Pass II) [directories] 

23:07:55> DUMP: estimated 704896 blocks (344. 1 9MB) 

23:07:57> DUMP: dumping (Pass HI) [directories] 

23:08:27> DUMP: dumping (Pass IV) [regular files] 

23:13:43> DUMP: 23.81% done, finished in 0:16 

23 : 1 7:57> DUMP: 48.76% done, finished in 0: 1 0 

23:23: 15> DUMP: 76.28% done, fmished in 0:04 

23:27:21> DUMP: level 8 dump on Wed Nov 9 23:05:00 1994 

23:27:21> DUMP: 702906 blocks (343.22MB) 

23:27:2 1> DUMP: DUMP IS DONE 

23:27;28> Backup command completed successfijlly. 

23:27:33> 

23:27:33> Request Statistics: 
23 :27:33> Data written : 35 1480 KB 
23:27:33> Elapsed time : 00:23:15 
23:27:33> Status : Successful 
23:27:33> Performance : 251 KB/sec 
23:27:33> Peak rate : 375 KB/sec 
23:27:34> Write Retries: 694 
23:27:34>- 
23:27:34>- 


23:27:34> Request Identification (#8): 

23:27:34> Requestor : root@auspexO 

23:27:34> Id :vpl03 

23:27:34> Path : auspexO:/s3Q 

23:27:34> Type : dump 

23:27:34> File History : Maintained 

23:27:35> Volume label : incr_7 

23:27:35> File number :3 

23:27:35> 

23:27:48> DUMP; Date of this level 8 dump: Wed Nov 9 23:27:43 1994 

23:27:48> DUMP: Date of last level 3 dump: Tue Nov 8 22:47:00 1994 

23:27:49> DUMP: Dumping /dev/rvpl 03 (/s30) to standard output 

23:27:50> DUMP: mapping (Pass I) [regular files] 

23:29:45> DUMP; mapping (Pass II) [directories] 

23:30:28> DUMP: estimated 274 blocks (137KB) 

23 :30:28> DUMP: dumping (Pass 111) [directories] 

23:30:48> DUMP: dumping (Pass IV) [regular files] 

23:30:57> DUMP: level 8 dump on Wed Nov 9 23:27:43 1994 
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23:30;57> DUMP: 2528 blocks (1.23MB) 

23:30:57> DUMP: DUMP IS DONE 

23:30:S8> Backup command completed successfully. 

23:31:10> 

23 :3 1 : 1 0> Request Statistics: 
23:3 1 : 10> Data written : 1320 KB 
23 :3 1 : 10> Elapsed time : 00:03:36 
23 :3 1 : 10> Status : Successful 
23 :3 1 : 1 0> Performance : 6 KB/sec 
23:31:10> Peak rate :0 KB/sec 

23:31:10> 

23:31:11> 

23:31: 1 1> Request Identification (#9): 

23 :3 1 : 1 1> Requestor : root@auspexO 

23:31:1 1> Id : vpl04 

23 :3 1 : 1 1 > Path : auspexO:/s3 1 

23:3 l:n> Type : dump 

23:3 1 : Il> File History : Maintained 

23 :3 1 : 1 1 > Volume label : incr_7 

23:3 1:1 1> File number :4 

23:31;n> 

23 :3 1 :25> DUMP: Date of tiiis level 8 dump: Wed Nov 9 23:3 1 :20 1 994 

23 :3 1 :25> DUMP: Date of last level 3 dump: Tue Nov 8 22:50:46 1 994 

23:3 1 :25> DUMP: Dumping /dev/rvpl04 (/s3 1) to standard output 

23:3 1 :26> DUMP: mapping (Pass 1) [regular files] 

23:33:22> DUMP: mapping (Pass II) [directories] 

23:34:02> DUMP: mapping (Pass II) [directories] 

23:34: 16> DUMP: mapping (Pass II) [directories] 

23;34.25> DUMP: estimated 128840 blocks (62.91MB) 

23:34:35> DXJTMP: dumping (Pass III) [directories] 

23:34:54> DUMP: dumping (Pass IV) [regular files] 

23:39;28> DUMP: 97.75% done, finished in 0:00 

23:39:36> DUMP: level 8 dump on Wed Nov 9 23:31:201994 

23:39:36> DUMP: 129120 blocks (63.05MB) 

23:39:36> DUMP: DUMP IS DONE 

23:39:41> Backup command completed successfully. 

23:39.45> 

23:39:45> Request Statistics: 
23:39:45> Data written : 64620 KB 
23:39:45> Elapsed time : 00:08:34 
23:39:45> Status : Successtul 
23:39:45> Performance : 125 KB/sec 
23:39:45> Peak rate : 352 KB/sec 
23:39:46> Write Retries: 67 

23:39:46> Request Identification (#10): 

23:39:46> Requestor : root@auspexO 

23:39:46> Id : vpl05 

23:39:46> Path : auspex0:/s32 

23:39:46> Type : dump 

23 :39:46> File History : Maintained 

23:39:47> Volume label : incr_7 

23:39:47> File number : 5 

23:39:47> 

23:40:01> DUMP: Date of this level 8 dump: Wed Nov 9 23:39:55 1994 

23:40:01> DUMP: Date of last level 3 dump: Tue Nov 8 22:55:24 1994 

23 :40:0 1 > DUMP: Dumping /dev/rvp 105 (/s32) to standard output 

23:40:03> DUMP: mapping (Pass I) [regular files] 

23:42:02> DUMP: mapping (Pass U) [directories] 

23:42:40> DUMP: mapping (Pass II) [directories] 
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23:42:57> DUMP: mapping (Pass II) [directories] 

23:43:04> DUMP: mapping (Pass 11) [directories] 

23 :43 :09> DUMP: estimated 196618 blocks (96.00MB) 

23:43:11> DUMP: dumping (Pass III) [directories] 

23 :43 : 1 6> DUMP: dumping (Pass IV) [regular files] 

23:48:44> DUMP: 89.53% done, finished in 0:00 

23:48;48> DUMP: level 8 dump on Wed Nov 9 23:39:55 1994 

23:48:48> DUMP: 196752 blocks (96.07MB) 

23:48:48> DUMP: DUMP IS DONE 

23:48:49> Backup command completed successfully. 

23:48:53> 

23:48:53> Request Statistics: 
23:48:53> Data written : 98400 KB 
23:48:53> Elapsed time : 00:09:07 
23:48: 5 3> Status : Successful 
23:48:53> Performance : 179 KB/sec 
23:48:53> Peak rate : 352 KB/sec 
23:48:54> Write Retries: 61 

23:48:54> 

23:48:55> 

23:48:55> Request Identification (#1 1): 
23:48:55> Requestor : root@auspexO 
23:48:55> Id :vpl06 
23:48:55> Path : auspexO:/s33 
23:48:55> Type : dump 
23:48:55> File History ; Maintained 
23:48:55> Volume label : incr_7 
23:48:55> File number : 6 
23:48:55> 

23:49:11> DUMP: Date of this level 8 dump: Wed Nov 9 23:49:06 1994 

23:49:1 1> DUMP: Date of last level 3 dump: Tue Nov 8 23:05:41 1994 

23 :49: n > DUMP: Dumping /dev/rvp 1 06 (/s3 3) to standard output 

23:49: 12> DUMP: mapping (Pass I) [regular files] 

23:5 1 :09> DUMP: mapping (Pass II) [directories] 

23:52:30> DUMP: mapping (Pass II) [directories] 

23:53:09> DUMP: mapping (Pass II) [directories] 

23:53:25> DUMP: mapping (Pass 11) [directories] 

23;53;33> DUMP: mapping (Pass II) [directories] 

23:53:39> DUMP: estimated 91984 blocks (44.91MB) 

23:53 :45> DUMP: dumping (Pass HI) [directories] 

23:53:5 1> DUMP: dumping (Pass IV) [regular files] 

23:56:33> DUMP: level 8 dump on Wed Nov 9 23:49:06 1994 

23:56:33> DUMP: 91956 blocks (44.90MB) 

23:56:33> DUMP: DUMP IS DONE 

23:56:35> Backup command completed successfully. 

23:56:38> 

23:56:38> Request Statistics: 
23:56:38> Data written : 46020 KB 
23:56:3 8> Elapsed time : 00:07:43 
23:56:38> Status : Successful 
23:56:38> Performance : 99 KB/sec 
23:56:38> Peak rate : 352 KB/sec 
23:56:39> Write Retries: 53 

23:56:39> 

23:56:41> 

23:56:41> Request Identification (#12): 
23:56:41> Requestor : root@auspexO 
23:56:41> Id : vpl07 
23:56:41> Path : auspex0:/s34 
23:56:41> Type : dump 
23:56:41> File History : Maintained 
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23:56:42> Volume label : mcr__7 
23:56:42> File number :7 
23:56:42> 

23:56:55> DUMP: Date of this level 8 dump: Wed Nov 9 23:56:50 1994 

23:56:55> DUMP: Date of last level 3 dump: Tue Nov 8 23:13:12 1994 

23 :56: 5 5> DUMP: Dumping /dev/rvp 107 (/s34) to standard output 

23:56:55> DUMP: mapping (Pass I) [regular files] 

23:58:49> DUMP: mapping (Pass II) [directories] 

00:00;30> DUMP: mapping (Pass II) [directories] 

00:01:03> DUMP: estimated 7506 blocks (3.67MB) 

00:0 1 : 1 0> DUMP: dumping (Pass III) [directories] 

00:0 1 :30> DUMP: dumping (Pass IV) [regular files] 

00:01:57> DUMP: level 8 dump on Wed Nov 9 23:56:50 1994 

00:01 :57> DUMP: 9564 blocks (4.67MB) 

00:01:57> DUMP: DUMP IS DONE 

00:01 :59> Backup command completed successfully. 

00:02:03> 

00:02:03> Request Statistics: 
00:02:03> Data written : 4800 KB 
00:02:03> Elapsed time : 00:05:22 
00:02:04> Status : Successful 
00:02:04> Performance : 14 KB/sec 
00:02:04> Peak rate : 0 KB/sec 
00:02 :04> Write Retries: 4 

00:02:04> 

00:02:05> 

00;02;05> Request Identification (#13): 
00:02: 05> Requestor : root@auspexO 
00:02:05> Id : vpl08 
00:02: 05> Path : auspexO:/s35 
00:02:05> Type : dump 
00:02:05> File History : Maintained 
00:02: 06> Volume label : incr_7 
00:02:06> File number : 8 
00:02:06> 

00:02: 17> DUMP: Date of this level 8 dump: Thu Nov 10 00:02:13 1994 

00:02:18> DUMP: Date of last level 3 dump: Tue Nov 8 23:18:07 1994 

00:02: 1 8> DUMP: Dumping /dev/rvpl08 (/s35) to standard output 

00:02: 1 8> DUMP: mapping (Pass I) [regular files] 

00:04: 02> DUMP: mapping (Pass II) [directories] 

00:06:24> DUMP: estimated 250 blocks (125KB) 

00:06:28> DUMP: dumping (Pass III) [directories] 

00:08:44> DUMP: dumping (Pass IV) [regular files] 

00:08:52> DUMP: level 8 dump on Thu Nov 10 00:02:13 1994 

00:08:53> DUMP: 15496 blocks (7.57MB) 

00:08:53> DUMP: DUMP IS DONE 

00:09:08> Backup command completed successfully. 

00:09:13> 

00:09: 13> Request Statistics: 
00:09: 13> Data written ; 7800 KB 
00:09: 1 3> Elapsed time : 00:07:08 
00:09: 1 3> Status : Successful 
00:09: 13> Performance : 18 KB/sec 
00:09: 13> Peak rate : 16 KB/sec 
00:09: 13> Write Retries: 1 

00:09: 13> 

00:09: 14> 

00:09: 14> Request Identification (#14): 
00:09: 14> Requestor : root@auspexO 
00:09: 14> Id :vpl09 
00:09: 14> Path : auspex0:/s36 
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00:09: 14> Type : dump 
00:09: 14> File History : Maintained 
00:09: 14> Volume label : incr_7 
00:09: 14> File number : 9 
00:09: 14> 

00:09:25> DUMP: Date of this level 8 dump: Thu Nov 10 00:09:21 1994 

00:09:25> DUMP: Date of last level 3 dump: Tue Nov 8 23:34:45 1994 

00:09:25> DUMP: Dumping /dev/rvp 109 (/s36) to standard output 

00:09:26> DUMP: mapping (Pass I) [regular files] 

00: 1 1 : 05> DUMP: mapping (Pass II) [directories] 

00: 1 1 :23> DUMP: mapping (Pass 11) [directories] 

00: 1 1 :30> DUMP: estimated 26 11 66 blocks (127.52MB) 

00: 1 1 :34> DUMP: dumping (Pass III) [directories] 

00: 1 1 :38> DUMP: dumping (Pass IV) [regular files] 

00:16;46> DUMP: 85.12% done, finished in 0:00 

00:17:27> DUMP: level 8 dump on Thu Nov 10 00:09:21 1994 

00:17:27> DUMP: 261534 blocks (127.70MB) 

00: 1 7:27> DUMP: DUMP IS DONE 

00:17:28> Backup command completed successfully. 

00:17:33> 

00:17:33> Request Statistics: 
00: 1 7 : 3 3> Data written : 1 30800 KB 
00: 1 7:33> Elapsed time : 00:08: 19 
00:17:33> Status : Successful 
00:17:33> Performance : 262 KB/sec 
00:17:33> Peak rate : 428 KB/sec 
00: 1 7:33> Write Retries: 148 

00:17:33> 

00:17:34> 

00: 1 7:34> Request Identification (#1 5): 
00:17:34> Requestor : root@auspexO 
00:17:34> Id :vplIO 
00:I7:34> Path : auspex0:/s37 
00:1 7: 34> Type : dump 
00: 1 7:34> File History : Maintained 
00:17:34> Volume label : incr_7 
00:17:34> File number : 10 
00:17:34> 

00:17:45> DUMP: Date of this level 8 dump: Thu Nov 10 00:17:41 1994 

00:17:45> DUMP: Date of last level 3 dump: Tue Nov 8 23:40:05 1994 

00: 1 7:45> DUMP: Dumping /dev/rvp 1 1 0 (/s3 7) to standard output 

00: 1 7:46> DUMP: mapping (Pass I) [regular files] 

00: 1 9:29> DUMP: mapping (Pass II) [directories] 

00: 1 9: 3 1 > DUMP: mapping (Pass 11) [directories] 

00: 1 9:33> DUMP: estimated 586798 blocks (286.52MB) 

00:19:39> DUMP: dumping (Pass III) [directories] 

00:19:39> DUMP: dumping (Pass IV) [regular files] 

00:24:44> DUMP: 39. 1 0% done, fmished in 0:07 

00:29:4 1> DUMP: 81.29% done, fmished in 0:02 

00:32:21> DUMP: level 8 dump on Thu Nov 10 00:17:41 1994 

00:32:21> DUMP: 587200 blocks (286.72MB) 

00:32:21> DUMP: DUMP IS DONE 

00:32:22> Backup command completed successfully. 

00:32:27> 

00:32:27> Request Statistics: 
00:32:27> Data written : 293640 KB 
00:32:27> Elapsed time : 00: 14:53 
00:32:27> Status : Successful 
00:32:27> Performance : 328 KB/sec 
00:32:27> Peak rate : 428 KB/sec 
00:32:27> Write Retries: 256 
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00:32:27> 

00:32:28> 

00:32:28> Request Identification (#16): 
00:32:28> Requestor : root@auspexO 
00:32:28> Id rvplll 
00:32:28> Path : auspexO:/s38 
00:32:28> Type : dump 
00:32:28> File History : Maintained 
00:32:28> Volume label : incr_7 
00:32:28> File number : 1 1 
00:32:28> 

00:32 :39> DUMP: Date of this level 8 dump: Thu Nov 10 00:32:35 1994 

00:32 :39> DUMP: Date of last level 3 dump: Tue Nov 8 23:46:14 1994 

00:32:40 DUMP: Dumping /dev/rvp 1 1 1 (/s3 8) to standard output 

00:32:40> DUMP: mapping (Pass I) [regular files] 

00:34:20 DUMP: mapping (Pass 11) [directories] 

00:36: 15> DUMP: mapping (Pass II) [directories] 

00:37:20> DUMP: mapping (Pass II) [directories] 

00:37 :50> DUMP: mapping (Pass II) [directories] 

00:37:57> DUMP: mapping (Pass II) [directories] 

00:38:0 1> DUMP: mapping (Pass II) [directories] 

00:38:04> DUMP: estimated 8816 blocks (4.30MB) 

00;38:05> DUMP: dumping (Pass III) [directories] 

00:38: 10> DUMP: dumping (Pass IV) [regular files] 

00:38:35> DUMP: level 8 dump on Thu Nov 10 00:32:35 1994 

00:38:35> DUMP: 8942 blocks (4.37MB) 

00:38:35> DUMP: DUMP IS DONE 

00:38:35> Backup command completed successfully, 

00:38:39> 

00:38:39> Request Statistics: 
00:38:39> Data written : 4500 KB 
00:38:39> Elapsed time : 00:06: 1 1 
00:38:39> Status : Successful 
00:38:39> Performance : 12 KB/sec 
00:38:39> Peak rate : 0 KB/sec 
00:38:40> Write Retries: 4 

00:38:40> 

00:38:40> 


00:38:40> Request Identification (#17): 

00:38:40> Requestor : root@auspexO 

00:38:40> Id :vpll2 

00:38:40> Path : auspex0:/s39 

00:38:40> Type : dump 

00:38:40> File History : Maintained 

00:38:42> Volume label : incr_7 

00:38:42> File number : 12 

00:38:42> 

00:38:52> DUMP: Date of this level 8 dump: Thu Nov 10 00:38:48 1994 

00:38:52> DUMP: Date of last level 3 dump: Wed Nov 9 00:01:25 1994 

00:38:53> DUMP: Dumping /dev/rvp 1 1 2 (/s39) to standard output 

00:38:53> DUMP: mapping (Pass I) [regular files] 

00:40:34> DUMP: mapping (Pass II) [directories] 

00:40:54> DUMP: mapping (Pass II) [directories] 

00:41:07> DUMP: estimated 239828 blocks (1 17.10MB) 

00:41 :08> DUMP: dumping (Pass III) [directories] 

00:41 :37> DUMP: dumping (Pass IV) [regular files] 

00:46:25> DUMP: 92.27% done, fmished in 0:00 

00:46:38> DUMP: level 8 dump on Thu Nov 10 00:38:48 1994 

00:46:38> DUMP: 240468 blocks (1 17.42MB) 

00:46:38> DUMP: DUMP IS DONE 

00:46:40> Backup command completed successluUy. 
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00:46:43> 

00:46:43> Request Statistics: 
00:46:43> Data written : 120240 KB 
00:46:43> Elapsed time : 00:08:03 
00:46:43> Status : Successful 
00:46;43> Performance : 248 KB/sec 
00:46 :43> Peak rate : 428 KB/sec 
00:46 :44> Write Retries: 83 

00:46:44> 

00:46:45> - 


00:46:45> Request Identification (#18): 
00;46:45> Requestor : root@auspexO 
00:46:45> Id :vpll3 
00:46:45> Path : auspex0:/s40 
00:46:45> Type :dump 
00:46:45> File History : Maintained 
00:46:46> Volume label : incr_7 
00:46:46> File number : 13 
00:46:46> 

00:46:56> DUMP: Date of this level 8 dump: Thu Nov 10 00:46:53 1994 

00:46:56> DUMP: Date of last level 3 dump: Wed Nov 9 00:05:56 1994 

00:46:57> DUMP: Dumping /dev/rvpl 13 (/s40) to standard output 

00:46:57> DUMP: mapping (Pass I) [regular files] 

00:48:3 8> DUMP: mapping (Pass II) [directories] 

00:48:40> DUMP: estimated 54 blocks (27KB) 

00:48:4 1> DUMP: dumping (Pass III) [directories] 

00:48:42> DUMP: dumping (Pass IV) [regular files] 

00:48:47> DUMP: level 8 dump on Thu Nov 10 00:46:53 1994 

00:48:47> DUMP: 502 blocks (251KB) 

00:48:47> DUMP: DUMP IS DONE 

00:48:48> Backup command completed successfully. 

00:48:59> 

00:48:59> Request Statistics: 
00:48:59> Data written : 300 KB 
00:48:59> Elapsed time : 00:02:14 
00:48:S9> Status : Successtiil 
00:48:59> Performance : 2 KB/sec 
00:48:59> Peak rate :0 KB/sec 

00:49:00> 

00:49:00> 

00:49:00> Request Identification (#19): 
00:49:00> Requestor : root@auspexO 
00:49:01> Id :vpll4 
00:49:01> Path ; auspexO:/s41 
00:49:01> Type : dump 
00:49:01> File History : Maintained 
00:49:01> Volume label : incr_7 
00:49:01> File number : 14 
00:49:01> 

00:49:12> DUMP: Date of this level 8 dump: Thu Nov 10 00:49:08 1994 

00:49:12> Dl/MP: Date of last level 3 dump: Wed Nov 9 00:09:37 1994 

00:49 : 1 2> DUMP: Dumping /dev/rvp 1 1 4 (/s4 1 ) to standard output 

00:49: 1 3> DUMP: mapping (Pass I) [regular files] 

00:50:52> DUMP: mapping (Pass II) [directories] 

00:5l:00> DUMP: estimated 250 blocks (125KB) 

00:5 1 :05> DUMP: dumping (Pass III) [directories] 

00:5 1 :09> DUMP: dumping (Pass IV) [regular files] 

00:5 1 : 12> DUMP: level 8 dump on Thu Nov 1 0 00:49:08 1 994 

00:5 1 : 1 2> DUMP: 906 blocks (453KB) 

00:51:12> DUMP: DUMP IS DONE 

00:51:13> Backup command completed successfully. 
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00:51:25> 

00:51:25> Request Statistics: 
00:51 :25> Data written : 480 KB 
00:5 1 :25> Elapsed time : 00:02:25 
00:51 :25> Status : Successful 
00:51 :25> Performance : 3 KB/sec 
00:51:25> Peak rate :0 KB/sec 

00:51:25> 

00:51:26>- 


00:51 :26> Request Identification (#20): 
00:51 :26> Requestor : root@auspexO 
00:51:26> Id :vpll5 
00:51:26> Path : auspex0:/s42 
00:51:26> Type : dump 
00:5 1 :26> File History : Maintained 
00:51:27> Volume label : incr_7 
00:51:27> File number : 1 5 
00:51 :27> 

00:5 1 :37> DUMP: Date of this level 8 dump: Thu Nov 1 0 00:5 1 :34 1 994 

00:5 1 :37> DUMP: Date of last level 3 dump: Wed Nov 9 00: 12: 1 5 1 994 

00 ; 5 1 :37> DUMP: Dumping /dev/rvp 1 1 5 (/s42) to standard output 

00:51 :39> DUMP: mapping (Pass I) [regular files] 

00:53 :20> DUMP: mapping (Pass II) [directories] 

00:53:34> DUMP: mapping (Pass II) [directories] 

00:53:44> DUMP: mapping (Pass II) [directories] 

00:53:48> DUMP: estimated 8272 blocks (4.04MB) 

00:53:49> DUMP: dumping (Pass III) [directories] 

00 :53 : 5 8> DUMP: dumping (Pass IV) [regular files] 

00:54:3 1 > DUMP: level 8 dump on Thu Nov 1 0 00:5 1 :34 1 994 

00:54:31> DUMP: 8338 blocks (4.07MB) 

00:54:31> DUMP: DUMP IS DONE 

00:54:32> Backup command completed successfully. 

00:54:35> 

00:54:35> Request Statistics: 
00:54:35> Data written : 4200 KB 
00:54:35> Elapsed time : 00:03:09 
00:54:35> Status : Successful 
00:54:35> Performance : 22 KB/sec 
00:54:35> Peak rate :0 KB/sec 
00:54:36> Write Retries: 4 

00:54:36> 

00:54:36> 

00:54:36> Request Identification (#21): 
00:54:36> Requestor : root@auspexO 
00:54:36> Id :vpll6 
00:54:36> Path : auspex0:/s43 
00:54:36> Type : dump 
00:54:36> File History : Maintained 
00:54:37> Volume label : incr_7 
00:54:37> File number : 16 


00:54:37> 

00:54:48> DUMP: Date of this level 8 dump: Thu Nov 10 00:54:43 1994 

00:54:48> DUMP: Date of last level 3 dump: Wed Nov 9 00:17:44 1994 

00:54:48> DUMP: Dumping /dev/rvp 1 1 6 (/s43) to standard output 

00:54:49> DUMP: mapping (Pass I) [regular files] 

00: 5 6:2 8> DUMP: mapping (Pass II) [directories] 

00:56:30> DUMP: estimated 50 blocks (25KB) 

00:56:3 1> DUMP: dumping (Pass III) [directories] 

00:56:32> DUMP: dumping (Pass IV) [regular files] 

00:56:38> DUMP: level 8 dump on Thu Nov 10 00:54:43 1994 

00:56:38> DUMP: 498 blocks (249KB) 
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00:56:39> DUMP: DUMP IS DONE 

00:56:39> Backup command completed successfully. 

00:56:5 1> 

00:56:5 1> Request Statistics: 
00:56:5 1> Data written : 300 KB 
00:56:5 1 > Elapsed time : 00:02:15 
00:56:5 1 > Status : Successful 
00:56:5 1 > Performance : 2 KB/sec 
00:56:5 1> Peak rate :0 KB/sec 

00:56:5 1 > 

00:56:52> 

00:56:52> Request Identification (#22): 
00:56:52> Requestor : root@auspexO 
00:56:52> Id :vpll7 
00:56:52> Path : auspex0:/s44 
00:56:52> Type : dump 
00:56:52> File Histoiy : Maintained 
00:56:5 3> Volume label : incr_7 
00:56:53> File number : 17 
00:56:53> 

00:57:05> DUMP: Date of this level 8 dump: Thu Nov 10 00:57:01 1994 

00:57:05> DUMP: Date of last level 3 dump: Wed Nov 9 00:19:57 1994 

00:57:05> DUMP: Dumping /dev/rvp 1 1 7 (/s44) to standard output 

00:57:05> DUMP: mapping (Pass I) [regular files] 

00:57:53> DUMP: mapping (Pass II) [directories] 

00:57:53> DUMP: estimated 50 blocks (25KB) 

00:57:54> DUMP: dumping (Pass 111) [directories] 

00:57:55> DUMP: dumping (Pass IV) [regular files] 

00:57:59> DUMP: level 8 dump on Thu Nov 10 00:57:01 1994 

00:57:59> DUMP: 274 blocks (137KB) 

00:57:59> DUMP: DUMP IS DONE 

00:58:00> Backup command completed successfully. 

00:58:05> 

00:58:05> Request Statistics: 
00:58:05> Data written : 1 80 KB 
00:58:05> Elapsed time : 00:01 : 13 
00:58:05> Status : Successful 
00:58:05> Performance : 2 KB/sec 
00:58:05> Peak rate :0 KB/sec 

00:58;06> 

00:58:06> Request Identification (#23): 

00:58:06> Requestor : root@auspexO 

00:58:06> Id : vp95 

00:58:06> Path : auspex0:/s22 

00:58:06> Type : dump 

00:58:06> File History : Maintained 

00:58:07> Volume label : incr_7 

00:58:07> File number : 18 

00:58:07> 

00:58:17> DUMP: Date of this level 8 dump: Thu Nov 10 00:58:14 1994 

00:58: 17> DUMP: Date of last level 3 dump: Wed Nov 9 00:21:13 1994 

00:58: 1 8> DUMP: Dumpmg /dev/rvp95 (/s22) to standard output 

00 : 58 : 1 8> DUMP: mapping (Pass I) [regular fl les] 

0 1 : 00 : 1 5> DUMP: mapping (Pass II) [directories] 

0 1 : 0 1 :3 1 > DUMP: mapping (Pass II) [directories] 

01:01 :56> DUMP: mapping (Pass II) [directories] 

01:02:09> DUMP: estimated 3230 blocks (1.58MB) 

01 :02: 1 1> DUMP: dumping (Pass III) [directories] 

01 :02:20> DUMP: dumping (Pass IV) [regular files] 

01 :02:39> DUMP: level 8 dump on Thu Nov 1 0 00:58: 14 1994 
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0 1 :02:39> DUMP: 4232 blocks (2.07MB) 

0 1 :02:39> DUMP: DUMP IS DONE 

01:02:40> Backup command completed successfully. 

0l:02:44> 

01 :02:44> Request Statistics: 
0 1 ;02:44> Data written : 2 1 60 KB 
0 1 :02:44> Elapsed time : 00:04:38 
01:02:44> Status : Successful 
01:02:44> Perfonnance :7KB/sec 
01:02:44> Peak rate :0KB/sec 
01:02:45> Write Retries: 3 

01:02:45> 

01:02:45> 


01:02:45> Request Identification (#24): 
01:02:4S> Requestor : root@auspexO 
01:02:45> Id : vp96 
01:02:45> Path : auspex0:/s23 
01:02:45> Type : dump 
01 :02:45> File Histoiy : Maintained 
01 :02:46> Volume label : incr_7 
01:02:46> File number : 19 
01:02:46> 

0l:02:57> DUMP: Date of this level 8 dump: ThuNov 10 01:02:53 1994 

01 :02:57> DUMP: Date of last level 3 dump: Wed Nov 9 00:26:29 1994 

0 1 :02:57> DUMP: Dumping /dev/rvp96 (/s23) to standard output 

01 :02:57> DUMP: mapping (Pass I) [regular files] 

0 1 :04:39> DUMP: mapping (Pass II) [directories] 

01 :09:24> DUMP: mapping (Pass II) [directories] 

0 1 : 1 1 :56> DUMP: mapping (Pass II) [directories] 

01:12:12> DUMP: estimated 69564 blocks (33.97MB) 

0 1 : 1 2: 1 2> DUMP; dumping (Pass III) [directories] 

01 : 12:32> DUMP: dumping (Pass IV) [regular files] 

01:17:47> DUMP: 15.01% done, finished in 0:28 

01:22:12> DUMP: 88.15% done, finished in 0:01 

01 :23:03> DUMP: level 8 dump on Thu Nov 1 0 01 :02:53 1994 

01:23:04> DUMP: 69748 blocks (34.06MB) 

01 :23 :04> DUMP: DUMP IS DONE 

01:23:12> Backup command completed successfiilly. 

01:23:22> 

01:23:22> Request Statistics: 
01:23;22> Data written : 34920 KB 
0 1 :23 :22> Elapsed time : 00:20:37 
01:23:22> Status : Successflil 
01:23:22> Perfonnance :28KB/sec 
01:23:22> Peak rate : 133 KB/sec 
01:23:23> Write Retries: 39 

01:23:23> 

01:23:24> 


01:23:24> Request Identification (#25): 

01:23:24> Requestor : root@auspexO 

01:23:24> Id : vp97 

01:23:24> Path : auspex0:/s24 

01:23:24> Type : dump 

01:23 :24> File History : Maintained 

01:23:25> Volume label : incr_7 

01:23:25> File number : 20 

01:23:25> 

01:23:42> DUMP: Date of this level 8 dump: ThuNov 10 01:23:38 1994 

01 :23:42> DUMP: Date of last level 3 dump: Wed Nov 9 00:37:50 1994 

0 1 :23 :42> DUMP: Dumping /dev/rvp97 (/s24) to standard output 

0 1 :23 :43> DUMP: mapping (Pass I) [regular files] 
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01 :27:58> DUMP: mapping (Pass II) [directories] 

01:31 :02> DUMP: mapping (Pass II) [directories] 

01:32:28> DUMP: mapping (Pass II) [directories] 

01 :32:58> DUMP: estimated 273276 blocks (133.44MB) 

01 :33:01> DUMP: dumping (Pass III) [directories] 

01 :34:56> DUMP: dumping (Pass IV) [regular files] 

01 :38:25> DUMP: 1 8.95% done, finished in 0:21 

0 1 :43:25> DUMP: 44.70% done, finished in 0: 12 

01 :47:58> DUMP: 74.04% done, finished in 0:05 

01:52:52> DUMP: level 8 dump on Thu Nov 10 01:23:38 1994 

01:52:52> DUMP: 273212 blocks (133.40MB) 

01:52:52> DUMP: DUMP IS DONE 

01 :52:56> Backup command completed successfully. 

01:53:04> 

01:53:04> Request Statistics: 
01 :53:04> Data written : 136620 KB 
01 :53:04> Elapsed time : 00:29:39 
01:53:04> Status : Successful 
01:5 3 :04> Performance : 76 KB/sec 
01:53:04> Peak rate : 162 KB/sec 
01:53:05> Write Retries: 1 37 

01:53:05> 

01:53:06> 


01 :53:06> Request Identification (#26): 

0 1 : 5 3 : 06> Requestor : root@auspexO 

01:53:06> Id : vp98 

01:53:06> Path : auspex0:/s25 

01:53:06> Type : dump 

01 :53:06> File History : Maintained 

01:53:07> Volume label : incr_7 

01:53:07> File number : 21 


01:53:07> 

01:53:23> DUMP: Dateofthis level 8dump: Thu Nov 10 01:53:19 1994 

01:53:23> DUMP: Date of last level 3 dump: Wed Nov 9 00:45:30 1994 

01 :53:24> DUMP: Dumping /dev/rvp98 (/s25) to standard output 

01 :53:24> DUMP: mapping (Pass I) [regular files] 

01 :57: 1 1> DUMP: mapping (Pass II) [directories] 

02:01:16> DUMP: estimated 274 blocks (137KB) 

02:0 1 :25> DUMP: dumping (Pass III) [directories] 

02:03 :37> DUMP: dumping (Pass IV) [regular files] 

02:03:42> DUMP: level 8 dump on Thu Nov 10 01:53:19 1994 

02:03:42> DUMP: 12216 blocks (5.96MB) 

02:03:42> DUMP: DUMP IS DONE 

02:04:00> Backup command completed successfully. 

02:04:07> 

02:04:07> Request Statistics: 
02:04:07> Data written : 6 120 KB 
02:04:07> Elapsed time : 00: 1 1 :00 
02:04:07> Status : Successful 
02:04:07> Performance : 9 KB/sec 
02:04:07> Peak rate : 9 KB/sec 
02:04:07> Write Retries: 3 

02:04:09> Request Identification (#27): 

02:04:09> Requestor : root@auspexO 

02:04:09> Id : vp99 

02:04:09> Path : auspex0:/s26 

02:04:09> Type : dump 

02:04:09> File History : Maintained 

02:04: 10> Volume label : incr 7 
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02:04: 10> File number :22 
02:04: 10> 


02:04:24> DUMP: Date of this level 8 dump: Thu Nov 10 02:04:20 1994 
02:04:24> DUMP: Date of last level 3 dump: Wed Nov 9 00:51:40 1994 

02:04:24> DUMP: Dumping /dev/rvp99 (/s26) to standard output 

02:04:26> DUMP: mapping (Pass I) [regular files] 

02:08: 1 8> DUMP: mapping (Pass II) [directories] 

02:08;30> DUMP: estimated 204 blocks (102KB) 

02:08:32> DUMP: dumping (Pass III) [directories] 

02:08:45> DUMP: dumping (Pass IV) [regular files] 

02:09:07> DUMP: level 8 dump on Thu Nov 10 02:04:20 1994 

02:09:07> DUMP: 1812 blocks (906KB) 

02:09:08> DUMP: DUMP IS DONE 

02:09: 10> Backup command completed successfully. 

02:09:23> 

02:09:23> Request Statistics: 
02:09:23> Data written : 960 KB 
02:09:23> Elapsed time : 00:05:14 
02:09:23> Status : Successful 
02:09:23> Performance : 3 KB/sec 
02:09:23> Peak rate : 0 KB/sec 

02:09:24> 

02:09:25> 


02:09:25> Request Identification (#28): 
02:09:25> Requestor : root@auspexO 
02:09:25> Id : vpl 
02:09:25> Path : auspexO:/sl 
02:09:25> Type : dump 
02:09:25> File History : Maintained 
02;09:26> Volume label : incr_7 
02:09:26> File number : 23 
02:09:26> 

02:09;39> DUMP: Date of this level 4 dump: Thu Nov 10 02:09:36 1994 

02:09:39> DUMP: Date of last level 0 dump: Sat Nov 5 02:10:15 1994 

02:09:40> DUMP: Dumping /dev/rvpl (/si) to standard output 

02:09:4 1> DUMP: mapping (Pass I) [regular files] 

02:12: 16> DUMP; mapping (Pass II) [directories] 

02: 1 3 :06> DUMP: mapping (Pass II) [directories] 

02:13:28> DUMP: estimated 83 102 blocks (40.58MB) 

02: 1 3 :28> DUMP: dumping (Pass III) [directories] 

02: 15:01 > DUMP: dumping (Pass IV) [regular files] 

02:18:35> DUMP: 68.30% done, finished in 0:02 

02:20:47> DUMP: level 4 dump on Thu Nov 10 02:09:36 1994 

02:20:49> DUMP: 838 1 8 blocks (40.93MB) 

02:20:50> DUMP: DUMP IS DONE 

02:20: 5 3> Backup command completed successfully. 

02:20:57> 

02:20:57> Request Statistics: 
02:20:57> Data written : 41940 KB 
02:20:57> Elapsed time : 00: 1 1 :32 
02:20:57> Status : Successfijl 
02:20:57> Performance : 60 KB/sec 
02:20:57> Peak rate : 200 KB/sec 
02:20:58> Write Retries: 66 

02:20:58> 

02:20:59> - 


02:20: 5 9> Request Identification (#29): 
02:20: 5 9> Requestor : root@auspexO 
02:20:59> Id :vplO 
02:20:59> Path : auspexO:/slO 
02:20:59> Type : dump 


Exhibit C8 


Page 301 of 598 


02:20:59> File History : Maintained 
02:2 1 :00> Volume label : incr_7 
02:21:00> File number :24 
02:21 :00> 

02:2 1 : 1 3> DUMP: Date of this level 4 dump: Thu Nov 10 02:2 1 :09 1 994 

02:2 1 : 1 3> DUMP: Date of last level 0 dump: Sat Nov 5 03 : 57: 53 1 994 

02 :2 1 : 1 3> DUMP: Dumping /de v/rvp 1 0 (/s 1 0) to standard output 

02:21 : 1 6> DUMP: mapping (Pass I) [regular files] 

02:23:30> DUMP: mapping (Pass II) [directories] 

02:24:40> DUMP: mapping (Pass II) [directories] 

02:25: 1 3> DUMP: mapping (Pass II) [directories] 

02:25:27> DUMP: estimated 172132 blocks (84.05MB) 

02:25:30> DUMP: dumping (Pass III) [directories] 

02:25:58> DUMP: dumping (Pass IV) [regular files] 

02:30:4 1> DUMP: 41 .86% done, finished in 0:07 

02:35:32> DUMP: 90.38% done, finished in 0:01 

02:36:40> DUMP: level 4 dump on Thu Nov 10 02:21:09 1994 

02:36:40> DUMP: 1 72372 blocks (84. 17MB) 

02:36:40> DUMP: DUMP IS DONE 

02:36:43> Backup command completed successfully. 

02:36:49> 

02:36:49> Request Statistics: 

02:36:49> Data written : 86220 KB 

02:36:49> Elapsed time : 00:15:50 

02:36:49> Status : Successful 

02:36:49> Performance : 90 KB/sec 

02:36:49> Peak rate : 272 KB/sec 

02:36:50> Write Retries; 105 

02:36:50> 

02:36:5 1> Request Identification (#30): 
02 : 3 6 : 5 1 > Requestor : root@auspexO 
02:36:5 1> Id : vp2 
02:36:5 1> Path : auspex0:/s2 
02:36:5 1> Type : dump 
02:36:5 1> File History : Maintained 
02:36:5 1> Volume label : incr_7 
02:36:51> File number : 25 
02:36:5 1> 

02:37:05> DUMP: Date of this level 4 dump: Thu Nov 10 02:37:02 1994 

02:37:05> DUMP: Date of last level 0 dump: Sat Nov 5 05: 1 8:24 1994 

02:37:07> DUMP: Dumping /dev/rvp2 (/s2) to standard output 

02:37:07> DUMP: mapping (Pass I) [regular files] 

02:39:33> DUMP: mapping (Pass II) [directories] 

02:40:45> DUMP: mapping (Pass II) [directories] 

02:41:08> DUMP: mapping (Pass II) [directories] 

02:4 1 : 1 9> DUMP: mapping (Pass 11) [directories] 

02:4 1 :27> DUMP: mapping (Pass 11) [directories] 

02:41:32> DUMP: estimated 24590 blocks (12.01MB) 

02:41:35> DUMP: dumping (Pass III) [directories] 

02:4 1 :57> DUMP: dumping (Pass IV) [regular files] 

02:43:18> DUMP: level 4 dump on Thu Nov 10 02:37:02 1994 

02:43: 1 8> DUMP: 24696 blocks (12.06MB) 

02:43: 19> DUMP: DUMP IS DONE 

02:43 :20> Backup command completed successfully. 

02:43 :24> 

02:43 :24> Request Statistics: 
02:43:24> Data written : 12360 KB 
02:43 :24> Elapsed time : 00:06:33 
02:43 :24> Status : Successful 
02:43:24> Performance : 3 1 KB/sec 
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02:43 :24> Peak rate :260KB/sec 
02:43 :25> Write Retries: 13 
02:43:25> - 
02:43:26> - 


02:43:26> Request Identification (#31): 
02:43:26> Requestor : root@auspexO 
02:43:26> Id :vp21 
02:43 :26> Path :auspexO:/s11 
02:43:26> Type : dump 
02:43 :26> File History : Maintained 
02:43 :27> Volume label : incr_7 
02:43:27> File number : 26 
02:43 :27> 

02:43:5l> DUMP: Date of this level 4 dump: Thu Nov 10 02:43:39 1994 

02:43:5 1> DUMP: Date of last level 0 dump: Sat Nov 5 08:3 1 :45 1994 

02:43:52> DUMP: Dumping /dev/rvp21 (/si 1) to standard output 

02:43:52> DUMP: mapping (Pass I) [regular files] 

02:47:00> DUMP: mapping (Pass II) [directories] 

02:47:37> DUMP: estimated 174 blocks (87KB) 

02:47:37> DUMP: dumping (Pass III) [directories] 

02:48:2 1 > DUMP: dumping (Pass IV) [regular files] 

02:48:42> DUMP: level 4 dump on Thu Nov 10 02:43:39 1994 

02:48:42> DUMP: 4324 blocks (2.1 1MB) 

02:48:42> DUMP: DUMP IS DONE 

02:48:5 1> Backup command completed successfully. 

02:49 :04> 

02:49 :04> Request Statistics: 
02:49 :04> Data written : 2220 KB 
02:49;04> Elapsed time : 00:05:38 
02:49:04> Status : Successful 
02:49:04> Performance :6KB/sec 
02:49:04> Peak rate :OKB/sec 

02:49:05> 

02:49:06> 

02:49:06> Request Identification (#32): 
02:49:06> Requestor : root@auspexO 
02:49:06> Id : vp22 
02:49:06> Path : auspex0:/sl2 
02:49:06> Type : dump 
02:49:06> File History : Maintained 
02:49:07> Volume label : incr_7 
02:49:07> File number : 27 


02:49:07> 

02:49:31> DUMP: Date of this level 4 dump: Thu Nov 10 02:49: 17 1994 

02:49:31> DUMP: Date of last level 0 dump: Sat Nov 5 08:55:55 1994 

02:49:3 1 > DUMP: Dumping /dev/rvp22 (/s 1 2) to standard output 

02:49:32> DUMP: mapping (Pass 1) [regular files] 

02:52:20> DUMP: mapping (Pass 11) [directories] 

02:53 :34> DUMP: mapping (Pass II) [directories] 

02:54: 13> DUMP: mapping (Pass II) [directories] 

02:54:29> DUMP: mapping (Pass II) [directories] 

02:54:44> DUMP: estimated 1070462 blocks (522.69MB) 

02:54:44> DUMP: dumping (Pass III) [directories] 

02 : 56: 1 3> DUMP: dumping (Pass IV) [regular flies] 

02:59:46> DUMP: 6.48% done, finished in 1:12 

03:04:57> DUMP: 1 5.97% done, finished in 0:52 

03:09:54> DUMP: 24.76% done, finished in 0:45 

03:14:53> DUMP: 34.09% done, finished in 0:38 

03:19:45> DUMP: 43.25% done, finished in 0:32 

03:24:46> DUMP: 53.90% done, finished in 0:25 

03 :30:04> DUMP: 64.36% done, finished in 0: 1 9 
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03:34:45> DUMP: 75.12% done, finished in 0:13 

03:39:45> DUMP: 86.95% done, finished in 0:06 

03:44:44> DUMP: 99.39% done, finished in 0:00 

03:45:09> DUMP: level 4 dump on Thu Nov 10 02:49:17 1994 

03:45:10> DUMP: 1070600 blocks (522.75MB) 

03:45:10> DUMP: DUMP IS DONE 

03:45:29> Backup command completed successfully. 

03:45:37> 

03:45:37> Request Statistics: 
03:45:37> Data written : 535320 KB 
03:45:37> Elapsed time : 00:56:31 
03:45:37> Status : Successful 
03:45:37> Performance : 157 KB/sec 
03:45:37> Peak rate : 250 KB/sec 
03:45:38> Write Retries: 772 

03:45:38> 

03:45:39> 

03:45:39> Request Identification (#33): 
03:45:39> Requestor : root@auspexO 
03:45:39> Id : vp23 
03:45:39> Path : auspex0:/sl3 
03:45:39> Type : dump 
03:45:39> File History : Maintained 
03:45:40> Volume label : incr_7 
03:45:40> File number : 28 
03:45:40> 

03:45:58> DUMP: Date of this level 4 dump: Thu Nov 10 03:45:50 1994 

03:45:58> DUMP: Date of last level 0 dump: Sat Nov 5 1 1:12:13 1994 

03 :45 :59> DUMP: Dumping /dev/rvp23 (/s 1 3) to standard output 

03:45:59> DUMP: mapping (Pass I) [regular files] 

03:49:00> DUMP: mapping (Pass II) [directories] 

03 :50: 1 2> DUMP: mapping (Pass II) [directories] 

03:50:39> DUMP: mapping (Pass II) [directories] 

03:50:55> DUMP: estimated 32868 blocks (16.05MB) 

03:50:56> DUMP: dumping (Pass III) [directories] 

03 :52:3 1> DUMP: dumping (Pass IV) [regular files] 

03:54: 10> DUMP: level 4 dump on Thu Nov 10 03:45:50 1994 

03:54:10> DUMP: 33182 blocks (16.20MB) 

03 :54: 1 0> DUMP: DUMP IS DONE 

03:54:20> Backup command completed successfully. 

03:54:27> 

03:54:27> Request Statistics: 
03:54:27> Data written : 16620 KB 
03:54:27> Elapsed time : 00:08:48 
03:54:27> Status : Successful 
03:54:27> Performance : 31 KB/sec 
03:54:27> Peak rate : 272 KB/sec 
03:54:27> Write Retries: 34 

03:54:27> 

03:54:28> 

03:54:28> Request Identification (#34): 
03:54:28> Requestor : root@auspexO 
03:54:28> Id : vp24 
03:54:28> Path : auspex0:/sl4 
03:54:28> Type : dump 
03:54:28> File History : Maintained 
03:54:29> Volume label : incr_7 
03:54:29> File number :29 
03:54:29> 

03:54:45> DUMP: Date of this level 4 dump: Thu Nov 10 03:54:38 1994 
03:54:45> DUMP: Date of last level 0 dump: Sat Nov 5 14:02:25 1994 
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03 ;54:45> DUMP: Dumping /dev/rvp24 (/s 1 4) to standard output 
03:54:47> DUMP: mapping (Pass I) [regular files] 
03:56:26> DUMP: mapping (Pass II) [directories] 
03:56:42> DUMP: mapping (Pass II) [directories] 
03:56:50> DUMP: mapping (Pass 11) [directories] 
03:56:56> DUMP: mapping (Pass II) [directories] 
03:56:58> DUMP: estimated 31002 blocks (15.14MB) 
03:57:0l> DUMP: dumping (Pass III) [directories] 
03:57:03> DUMP: dumping (Pass IV) [regular files] 
03:58:20 DUMP: level 4 dump on Thu Nov 10 03:54:38 1994 
03:58:20> DUMP: 31042 blocks (15.16MB) 
03:58:20> DUMP: DUMP IS DONE 
03:5 8:2 1> Backup command completed success&lly. 

03:58:25> 

03:58:25> Request Statistics: 
03:58:25> Data written : 15540 KB 
03:58:25> Elapsed time : 00:03:57 
03:58:25> Status : Successful 
03:58:25> Performance : 65 KB/sec 
03:58:25> Peak rate : 285 KB/sec 
03:58:25> Write Retries: 27 

03:58:25> 

03:58:26> 

03:58:26> Request Identification (#35): 
03:58:26> Requestor : root@auspexO 
03:58:26> Id : vp25 
03;58:26> Path : auspex0:/sl5 
03:58:26> Type : dump 
03:58:26> File History : Maintained 
03:58:27> Volume label : incr_7 
03:58:27> File number : 30 
03:58:27> 

03:58:40> DUMP: Date of this level 4 dump: Thu Nov 10 03:58:35 1994 

03:58:40> DUMP: Date of last level 0 dump: Sat Nov 5 14:51:55 1994 

03:58:4 1> DUMP: Dumping /dev/rvp25 (/si 5) to standard output 

03:58:42> DUMP: mapping (Pass I) [regular files] 

04:00:37> DUMP: mapping (Pass H) [directories] 

04:01 :36> DUMP: mapping (Pass II) [directories] 

04:02: 04> DUMP: mapping (Pass II) [directories] 

04:02: 1 1> DUMP: estimated 1 1 9740 blocks (58.47MB) 

04:02: 1 1> DUMP: dumping (Pass III) [directories] 

04:02:30> DUMP: dumping (Pass IV) [regular files] 

04:07: 14> DUMP: level 4 dump on Thu Nov 10 03:58:35 1994 

04:07: i4> DUMP: 1 19866 blocks (58.53MB) 

04:07: 14> DUMP: DUMP IS DONE 

04:07: 16> Backup command completed successfully. 

04:07:21> 

04:07:2 1> Request Statistics: 
04:07:21> Data written : 59940 KB 
04:07:21> Elapsed time : 00:08:55 
04:07:2 1> Status : Successful 
04:07:21> Performance : 112 KB/sec 
04:07:2 1> Peak rate : 315 KB/sec 
04:07 :22> Write Retries: 84 

04:07:22> 

04:07:22> 


04:07:22> Request Identification (#36): 
04:07:22> Requestor : root@auspexO 
04:07:22> Id : vp26 
04:07:22> Path : auspex0:/sl6 
04:07:22> Type : dump 
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04:07:22> File History : Maintained 
04:07:23> Volume label : incr_7 
04:07:23> File number :31 
04:07:23> 

04:07:38> DUMP: Date of this level 4 dump: Thu Nov 10 04:07:32 1994 

04:07:38> DUMP: Date of last level 0 dump: Sat Nov 5 16:01:46 1994 

04:07 :38> DUMP: Dumping /dev/rvp26 (/si 6) to standard output 

04:07:40> DUMP: mapping (Pass I) [regular files] 

04:09:23> DUMP: mapping (Pass II) [directories] 

04:10:04> DUMP: mapping (Pass II) [directories] 

04:10:22> DUMP: mapping (Pass II) [directories] 

04:1 0:3 3> DUMP: estimated 241700 blocks (1 1 8.02MB) 

04: 1 0:35> DUMP: dumping (Pass III) [directories] 

04: 1 4:48> DUMP: dumping (Pass IV) [regular files] 

04: 1 5:43> DUMP: 1 5.07% done, finished in 0:28 

04:20:45> DUMP: 88.62% done, finished in 0:01 

04:21 :39> DUMP: level 4 dump on Thu Nov 10 04:07:32 1994 

04:2l:40> DUMP: 241804 blocks (118,07MB) 

04:21 :40> DUMP: DUMP IS DONE 

04:22:5 1> Backup command completed successfully. 

04:23:04> 

04:23 :04> Request Statistics: 
04:23:04> Data written : 120960 KB 
04:23 :04> Elapsed time : 00: 1 5 :42 
04:23 :04> Status : Successful 
04:23 :04> Performance : 128 KB/sec 
04:23:04> Peak rate : 333 KB/sec 
04:23 :04> Write Retries: 196 

04:23:04> 

04:23 :05> 


04:23 :05> Request Identification (#37): 
04:23 :05> Requestor : root@auspexO 
04:23:05> Id : vp27 
04:23:05> Path : auspex0:/sl7 
04:23 :05> Type : dump 
04:23 :05> File History : Maintained 
04:23:05> Volume label : incr_7 
04:23:05> File number : 32 
04:23:05> 

04:23:20> DUMP: Date of this level 4 dump: Thu Nov 10 04:23:16 1994 

04:23:20> DUMP: Date of last level 0 dump: Sat Nov 5 18:40:18 1994 

04:23 :2 1> DUMP: Dumping /dev/rvp27 (/s 1 7) to standard output 

04:23:22> DUMP: mapping (Pass I) [regular files] 

04:25: 1 1> DUMP: mapping (Pass II) [directories] 

04:26:04> DUMP: mapping (Pass II) [directories] 

04:26:30> DUMP: mapping (Pass II) [directories] 

04:26:4 1> DUMP: estimated 193790 blocks (94.62MB) 

04:26:45> DUMP: dumping (Pass III) [directories] 

04:27:02> DUMP: dumping (Pass IV) [regular files] 

04:31:51> DUMP: 70.13% done, fmished in 0:02 

04:33:30> DUMP: level 4 dump on Thu Nov 10 04:23:16 1994 

04:33:30> DUMP: 193954 blocks (94.70MB) 

04:33:30> DUMP: DUMP IS DONE 

04:33 :33> Backup command completed successfully. 

04:33:37> 

04:33:37> Request Statistics: 
04:33:37> Data written : 97020 KB 
04:33 :37> Elapsed time : 00: 10:32 
04:33:37> Status : Successful 
04:33 :37> Performance : 153 KB/sec 
04:33 :37> Peak rate : 315 KB/sec 
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04:33:38> Write Retries: 229 

04:33:38> 

04:33:39> Request Identification (#38): 

04:33:39> Requestor : root@auspexO 

04:33:39> Id : vp28 

04:33:39> Path : auspexO:/sl8 

04:33:39> Type : dump 

04:33:39> File History : Maintained 

04:33:39> Volume label : incr_7 

04:33:39> File number : 33 

04:33:39> 

04:33:54> DUMP: Date of this level 4 dump: Thu Nov 10 04:33:48 1994 

04:33:54> DUMP: Date of last level 0 dump: Sat Nov 5 19:35:16 1994 

04:33:54> DUMP: Dumping /dev/rvp28 (/si 8) to standard output 

04:33:54> DUMP: mapping (Pass 1) [regular files] 

G4:35:52> DUMP: mapping (Pass 11) [directories] 

04:37:55> DUMP: mapping (Pass II) [directories] 

04:38:33> DUMP: mapping (Pass II) [directories] 

04:38:48> DUMP: estimated 884446 blocks (43 1 .86MB) 

04 ;3 8 :5 1 > DUMP: dumping (Pass III) [directories] 

04:43 :2 1 > DUMP: dumping (Pass IV) [regular files] 

04:44:15> DUMP: 2.38% done, finished in 3:26 

04:48:5 1> DUMP: 5.29% done, finished in 2:59 

04:54 :29> DUMP: 8.15% done, finished in 2:50 

04:58:58> DUMP: 10.72% done, finished in 2:47 

05:04: 10> DUMP; 13.51% done, finished in 2:40 

05:09:06> DUMP: 17.3 1% done, finished in 2:23 

05:13:59> DUMP: 20.60% done, finished in 2:15 

05:18:59> DUMP: 23.01% done, finished in 2:14 

05:24:1 1> DUMP: 25.67% done, finished in 2:10 

05:29:13> DUMP: 28.91% done, finished in 2:03 

05:34:08> DUMP: 31.36% done, finished in 2:00 

05:39: 10> DUMP: 33.84% done, finished in 1:57 

05:44:20> DUMP: 36.52% done, finished in 1:53 

05:49:08> DUMP: 39.57% done, finished in 1:47 

05:54 :23> DUMP: 42.32% done, finished in 1:42 

05:59:20> DUMP: 45.21% done, finished in 1:37 

06:04:16> DUMP: 48.17% done, finished in 1:31 

06:09: 17> DUMP: 51.1 5% done, finished m 1 :26 

06:14;19> DUMP: 54.09% done, finished m 1:20 

06: 1 9: 1 3> DUMP: 56.96% done, finished in 1 : 1 5 

06:24:22> DUMP: 60.02% done, finished m 1:10 

06:29: 1 4> DUMP: 63 .42% done, finished in 1 :03 

06:34:26> DUMP: 65.74% done, finished in 1 :00 

06:39: 16> DUMP: 68.43% done, finished in 0:55 

06:44:20> DUMP: 7 1 .00% done, finished in 0:51 

06:49:3 6> DUMP: 74.01% done, finished in 0:45 

06:54:26> DUMP: 76.84% done, finished in 0:40 

06:59:37> DUMP: 79.93% done, finished in 0:35 

07:04:34> DUMP: 82.99% done, finished in 0:29 

07:09:45> DUMP: 86.43% done, finished in 0:23 

07:14:43> DUMP: 89.17% done, finished in 0:18 

07: 1 9:35> DUMP: 92,26% done, finished in 0: 13 

07:24:47> DUMP: 94.99% done, finished in 0:08 

07:30:08> DUMP: 96.66% done, finished in 0:05 

07:33: 13> DUMP: level 4 dump on Thu Nov 10 04:33:48 1994 

07:33:13> DUMP: 872294 blocks (425.92MB) 

07:33:58> DUMP: DUMP IS DONE 

07: 34:5 7> Backup command completed successfully. 

07:35: 12> 


Exhibit C8 


Page 307 of 598 


07:35: 12> Request Statistics: 
07:35: 12> Data written : 436200 KB 
07:35:12> Elapsed time : 03:01:33 
07:35: 12> Status : Successful 
07:35: 12> Performance : 40 KB/sec 
07:35: 12> Peak rate : 75 KB/sec 
07:35:13> Write Retries: 1151 

07:35: 13> 

07:35: 14> 


07:35: 14> Request Idemiflcation (#39): 
07:35: 14> Requestor : root@auspexO 
07:35: 14> Id : vp29 
07:35:14> Path : auspex0:/sl9 
07:35: 14> Type : dump 
07:35: 14> File Histoiy : Maintained 
07:35: 1 5> Volume label : incr_7 
07:35: 15> File number : 34 
07:35:15> 

07:35:35> DUMP: Date of this level 4 dump: Thu Nov 10 07:35:27 1994 

07:35:35> DUMP: Date of last level 0 dump: Sat Nov 5 23:56:47 1994 

07:35:35> DUMP: Dumping /dev/rvp29 (/s 1 9) to standard output 

07:35:36> DUMP: mapping (Pass 1) [regular files] 

07:37:22> DUMP: mapping (Pass IT) [directories] 

07:38:26> DUMP: mapping (Pass 11) [directories] 

07:38:53> DUMP: mapping (Pass 11) [directories] 

07:39:03> DUMP: mapping (Pass 11) [directories] 

07:39: 1 1> DUMP: mapping (Pass II) [directories] 

07:39: 1 8> DUMP: estimated 46 1628 blocJcs (225.40MB) 

07:39: 1 9> DUMP: dumping (Pass III) [directories] 

07:40:00> DUMP: dumping (Pass IV) [regular files] 

07:44:29> DUMP: 17.46% done, finished in 0:24 

07:49:40> DUMP: 21.91% done, finished in 0:36 

07:54:35> DUMP: 38.65% done, finished in 0:24 

07:59:38> DUMP: 79.78% done, finished in 0:05 

08:02:19> DUMP: level 4 dump on Thu Nov 10 07:35:27 1994 

08:02:20> DUMP: 457076 blocks (223.18MB) 

08:02:20> DUMP: DUMP IS DONE 

08:02:3 1> Backup command completed successfully. 

08:02:37> 

08:02:37> Request Statistics: 
08:02:37> Data written : 228540 KB 
08:02:37> Elapsed time : 00:27:23 
08:02:37> Status : Successful 
08:02:37> Performance : 139 KB/sec 
08:02:37> Peak rate : 333 KB/sec 
08:02:38> Write Retries: 533 

08:02:38> 

08:02:39> 

08:02:39> Request Identification (#40): 
08:02:39> Requestor : root@auspexO 
08:02:39> Id : vp3 
08:02:39> Path : auspex0:/s3 
08:02:39> Type : dump 
08:02:39> File History : Maintained 
08:02:40> Volume label : incr_7 
08:02:40> File number : 35 
08:02:40> 

08:02:57> DUMP: Date of this level 4 dump: Thu Nov 10 08:02:49 1 994 
08:02:57> DUMP: Date of last level 0 dump: Sun Nov 6 01:31:17 1994 
08:02:57> DUMP: Dumping /dev/rvp3 (/s3) to standard output 
08:02:59> DUMP: mapping (Pass I) [regular files] 
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08:04:42> DUMP: mapping (Pass II) [directories] 
08:05:25> DUMP: estimated 300 blocks (150KB) 
08:05:30> DUMP: dumping (Pass III) [directories] 
08:05:53> DUMP: dumping (Pass IV) [regular files] 
08:06;00> DUMP: level 4 dump on Thu Nov 10 08:02:49 1994 
08:06:00 DUMP: 2270 blocks (1.1 1MB) 
08:06:00> DUMP: DUMP IS DONE 
08:06:02> Backup command completed successfully. 

08:06: 14> 

08:06: 14> Request Statistics: 
08:06: 14> Data written : 1 140 KB 
08:06: 14> Elapsed time : 00:03:35 
08:06: 14> Status : Successful 
08:06: 14> Performance : 5 KB/sec 
08:06: 14> Peak rate :0 KB/sec 

08:06: 15> 

08:06: 16> 

08:06: 16> Request Identification (#41): 
08:06: 16> Requestor : root@auspexO 
08:06: 16> Id : vp30 
08:06: 16> Path : auspexO:/s20 
08:06: 16> Type : dump 
08:06: 1 6> File History : Maintained 
08 :06: 1 7> Volume label : incr_7 
08:06; 17> File number : 36 
08:06: 17> 

08:06:32> DUMP: Date of this level 4 dump: Thu Nov 10 08:06:25 1994 

08:06:32> DUMP: Date of last level 0 dump: Sun Nov 6 03:52:31 1994 

08:06:32> DUMP: Dumping /dev/rvp30 (/s20) to standard output 

08:06:34> DUMP: mapping (Pass I) [regular files] 

08:08:27> DUMP: mapping (Pass 11) [directories] 

08:09:09> DUMP: mapping (Pass II) [directories] 

08:09:28> DUMP: mapping (Pass II) [directories] 

08:09:37> DUMP: estimated 137706 blocks (67.24MB) 

08:09:40> DUMP: dumping (Pass III) [directories] 

08: 1 0:08> DUMP: dumping (Pass IV) [regular files] 

08:14:32> DUMP: level 4 dump on Thu Nov 10 08:06:25 1994 

08:14:33> DUMP: 137910 blocks (67.34MB) 

08:14:33> DUMP: DUMP IS DONE 

08:1 4:3 6> Backup command completed successfully. 

08:14:40> 

08:14:40> Request Statistics: 
08 : 1 4:40> Data w^ritten : 69000 KB 
08:14:40> Elapsed time : 00:08:24 
08:14:40> Status : Successful 
08:14:40> Performance : 136 KB/sec 
08:14:40> Peak rate : 333 KB/sec 
08:14:41> Write Retries: 213 

08:14:4l> 

08:14:42> 

08:14:42> Request Identification (#42): 
08:I4:42> Requestor : root@auspexO 
08:14:42> Id : vp31 
08:14:42> Path : auspex0:/s21 
08:14:42> Type : dump 
08:14:42> File History : Maintained 
08:14:43> Volume label : incrJ7 
08:14:43> File number :37 
08:I4:43> 

08:14:58> DUMP: Date of this level 8 dump: Thu Nov 10 08:14:51 1994 
08:14:58> DUMP: Date of last level 3 dump: Wed Nov 9 03:04:43 1994 
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08 : 1 4:59> DUMP: Dumping /dev/rvp3 1 (/s2 1 ) to standard output 

08: 1 5:00> DUMP: mapping (Pass I) [regular files] 

08:15:49> DUMP: mapping (Pass II) [directories] 

08: 1 5:56> DUMP: mapping (Pass II) [directories] 

08: 1 6:00> DUMP: estimated 370974 blocks ( 1 8 L 1 4MB) 

08: 1 6:01 > DUMP: dumping (Pass III) [directories] 

08: 1 6:03> DUMP: dumping (Pass IV) [regular files] 

08:21 : 1 8> DUMP: 45.58% done, finished in 0:05 

08:26: 17> DUMP: 94,47% done, finished in 0:00 

08:26;41> DUMP: level 8 dump on Thu Nov 10 08:14:51 1994 

08:26:41> DUMP: 371 110 blocks (181.21MB) 

08:26:42> DUMP: DUMP IS DONE 

08:26:42> Backup command completed successfully. 

08:26:46> 

08:26:46> Request Statistics: 
08:26:46> Data written : 1 85580 KB 
08:26:46> Elapsed time : 00:12:04 
08:26:46> Status : Successful 
08:26:46> Perfonnance : 256 KB/sec 
08:26:46> Peak rate : 333 KB/sec 
08:26:47> Write Retries: 500 

08:26:47> 

08:26:48> 

08:26:48> Request Identification (#43): 
08:26:48> Requestor : root@auspexO 
08:26:48> Id : vp4 
08:26:48> Path : auspex0:/s4 
08:26:48> Type : dump 
08:26:48> File History ; Maintained 
08:26:49> Volume label : incr_7 
08:26:49> File number : 38 
08:26:49> 

08:27:04> DUMP: Date of this level 4 dump: Thu Nov 10 08:26:58 1994 

08:27:04> DUMP: Date of last level 0 dump: Sun Nov 6 05:29:50 1994 

08:27:04> DUMP: Dumping /dev/rvp4 (/s4) to standard output 

08:27:06> DUMP: mapping (Pass I) [regular files] 

08:28:50> DUMP: mapping (Pass II) [directories] 

08:3 1 : 1 5> DUMP: mapping (Pass II) [directories] 

08:32:03> DUMP: mapping (Pass II) [directories] 

08:32: 17> DUMP: estimated 216828 blocks (105.87MB) 

08:32:23> DUMP: dumping (Pass III) [directories] 

08:33:06> DUMP: dumping (Pass IV) [regular files] 

08:37:21> DUMP: 75.10% done, finished in 0:01 

08:39:09> DUMP: level 4 dump on Thu Nov 10 08:26:58 1994 

08:39:09> DUMP: 214964 blocks (104.96MB) 

08:39: 10> DUMP: DUMP IS DONE 

08:39: 13> Backup command completed successfully. 

08:39: 18> 

08:39: 18> Request Statistics: 
08:39: 1 8> Data written : 1 07520 KB 
08:39: 18> Elapsed time : 00:12:30 
08:39: 18> Status : Successful 
08:39: 18> Performance : 143 KB/sec 
08:39:18> Peakrate : 333 KB/sec 
08:39: 18> Write Retries: 279 

08:39: 18> 

08:39:19> 

08:39: 19> Request Identification (#44): 
08:39: 19> Requestor : root@auspexO 
08:39: 19> Id : vp5 
08:39: 19> Path : auspex0:/s5 
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08:39: 19> Type : dump 
08:39: 19> File History : Maintained 
08:39:20 Volume label : incr_7 
08:39:20> File number : 39 

08:39:20> 

08:39:35> DUMP: Date of this level 4 dump: Thu Nov 10 08:39:29 1994 

08:39:35> DUMP: Date of last level 0 dump: Sun Nov 6 07:47:43 1994 

08:39:36> DUMP: Dumping /dev/rvp5 (/s5) to standard output 

08:39:37> DUMP: mapping (Pass I) [regular files] 

08:41:26> DUMP: mapping (Pass II) [directories] 

08:42:43> DUMP: mapping (Pass II) [directories] 

08:43:15> DUMP: estimated 222652 blocks (108.72MB) 

08:43:23> DUMP: dumping (Pass III) [directories] 

08:44:0 1> DUMP: dumping (Pass IV) [regular files] 

08:48:23> DUMP: 59.26% done, finished in 0:03 

08:51:59> DUMP: level 4 dump on Thu Nov 1008:39:29 1994 

08:51:59> DUMP: 222424 blocks (108.61MB) 

08:5 1 :59> DUMP: DUMP IS DONE 

08:52:04> Backup command completed successfully. 

08:52:08> 

08:52:08> Request Statistics: 
08:52:08> Data written : 1 1 1240 KB 
08 : 52 :0 8> Elapsed time : 00: 1 2:49 
08:52:08> Status : Successful 
08:52:08> Performance : 144 KB/sec 
08:52:08> Peak rate ; 315 KB/sec 
08:52:08> Write Retries: 174 

08:52:08> 

08:52:09> 

08:52:09> Request Identification (#45): 
08:52:09> Requestor : root@auspexO 
08:52:09> Id : vp6 
08:52:09> Path : auspex0:/s6 
08:52:09> Type : dump 
08:52:09> File History : Maintained 
08:52: 10> Volume label : incr_7 
08:52: 10> File number : 40 
08:52:10> 

08:52 :24> DUMP: Date of this level 4 dump: Thu Nov 10 08:52:18 1994 

08:52:24> DUMP: Date of last level 0 dump: Sun Nov 6 09:54:49 1994 

08:52:25> DUMP: Dumping /dev/rvp6 (/s6) to standard output 

08:52:26> DUMP: mapping (Pass I) [regular files] 

08:54:24> DUMP: mapping (Pass II) [directories] 

08:56:00> DUMP: mapping (Pass II) [directories] 

08:56:34> DUMP: mapping (Pass II) [directories] 

08:56:47> DUMP: mapping (Pass II) [directories] 

08:56:54> DUMP: estimated 1 131 14 blocks (55.23MB) 

08:56:56> DUMP: dumping (Pass III) [directories] 

08:57:23> DUMP: dumping (Pass IV) [regular files] 

09:0 1 : 1 7> DUMP; level 4 dump on Thu Nov 1 0 08:52: 1 8 1 994 

09:0 1 : 1 7> DUMP: 11 3 1 74 blocks (55.26MB) 

09:0 1 : 1 7> DUMP: DUMP IS DONE 

09:0r:19> Backup command completed successfully. 

09:01:24> 

09:01:24> Request Statistics: 
09:0 1 :24> Data written : 56640 KB 
09:01 :24> Elapsed time : 00:09: 15 
09:01:24> Status : Successful 
09:01:24> Performance : 102 KB/sec 
09:01:24> Peak rate : 315 KB/sec 
09:01:25> Write Retries: 135 
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09:01 :25> 

09:0 1 :26^ ------ 

09:01 :26> Request Identification (#46): 
09:01 :26> Requestor : rDot@au5pexO 
09:01:26> Id : vp7 
09:01 :26> Path : auspex0:/s7 
09:01 :26> Type : dump 
09:01 :26> File History : Maintained 
09:01:26> Volume label : incr_7 
09:01 :26> File number : 41 
09:01 :26> 

09:01 :41> DUMP: Date of this level 4 dump: Thu Nov 10 09:01:36 1994 

09:0 1 :4 1> DUMP: Date of last level 0 dump: Sun Nov 6 11:1 9:07 1994 

09:01 :42> DUMP: Dumping /dev/rvp7 (/s7) to standard output 

09:01 :42> DUMP: mapping (Pass I) [regular files] 

09:03:35> DUMP: mapping (Pass II) [directories] 

09:04: 3 7> DUMP: mapping (Pass II) [directories] 

09:05 :02> DUMP: mapping (Pass II) [directories] 

09:05: 12> DUMP: mapping (Pass II) [directories] 

09:05:19> DUMP: estimated 2620 1 6 blocks (127.94MB) 

09:05 :26> DUMP: dumping (Pass III) [directories] 

09:05:53> DUMP: dumping (Pass IV) [regular files] 

09: 10:2 1> DUMP: 54.07% done, finished in 0:04 

09: 1 3 :52> DUMP: level 4 dump on Thu Nov 10 09:01 :36 1 994 

09:13:52> DUMP: 261908 blocks (127.88MB) 

09:13:52> DUMP: DUMP IS DONE 

09:13:35> Backup command completed successfully. 

09:13:59> 

09:I3:59> Request Statistics: 
09:13:59> Data written : 130980 KB 
09:13:59> Elapsed time : 00:12:33 
09:13:59> Status ; Successful 
09:13:59> Performance : 173 KB/sec 
09:13:59> Peak rate : 315 KB/sec 
09:14:00> Write Retries: 176 

09:14:00> 

09:14:01> 


09:14:01> Request Identification (#47): 
09: 1 4:0 1 > Requestor : root@auspexO 
09:14:01> Id : vp8 
09:14:01> Path : auspexO:/s8 
09:14:01> Type : dump 
09:1 4:01 > File History : Maintained 
09:14:01> Volume label : incr_7 
09:14:01> File number : 42 
09:14:01> 

09:14:17> DUMP: Date of this level 4 dump: Thu Nov 10 09:14:11 1994 

09:14:17> DUMP: Date of last level 0 dump: Sun Nov 6 12:32:01 1994 

09: 14: 1 7> DUMP: Dumping /de v/rvp8 (/s 8) to standard output 

09: 14: 1 8> DUMP: mapping (Pass I) [regular files] 

09: 1 6:09> DUMP: mapping (Pass II) [directories] 

09: 18:07> DUMP: mapping (Pass II) [directories] 

09: 18:45> DUMP: mapping (Pass II) [directories] 

09:19:02> DUMP: estimated 5 1 532 blocks (25.16MB) 

09: 1 9: 1 2> DUMP: dumping (Pass III) [directories] 

09: 1 9:29> DUMP: dumping (Pass IV) [regular files] 

09:21 :38> DUMP: level 4 dump on Thu Nov 10 09: 14: 1 1 1994 

09:21:38> DUMP: 49786 blocks (24.31MB) 

09:2 1 :40> DUMP: DUMP IS DONE 

09:2 1 :44> Backup command completed successfully. 

09:21:49> 
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09:21 :49> Request Statistics: 
09:2 1 :49> Data written : 24900 KB 
09:2 1 :49> Elapsed time : 00:07:48 
09:21:49> Status : Successful 
09:21 :49> Performance : 53 KB/sec 
09:2 1 :49> Peak rate : 3 1 5 KB/sec 
09:2 1 :50> Write Retries: 38 

09:21:50> 

09:21:52>- 


09:21 :52> Request Identification (#48): 

09:21 :52> Requestor : root@auspexO 

09:21 :52> Id : vp9 

09:21 :52> Path : auspex0:/s9 

09:21:52> Type : dump 

09:2 1 :52> File History : Maintained 

09:21 :53> Volume label : incr_7 

09:21 :53> File number : 43 

09:21 :53> 

09:22: 10> DUMP: Date of this level 4 dump: ThuNov 10 09:22:04 1994 

09:22: 10> DUMP: Date of last level 0 dump: Sun Nov 6 15:04:58 1994 

09:22: 1 1 > DUMP: Dumping /dev/rvp9 (/s9) to standard output 

09:22:1 3> DUMP: mapping (Pass I) [regular files] 

09:24:0 1> DUMP: mapping (Pass 11) [directories] 

09:24:27> DUMP: mapping (Pass II) [directories] 

09:24:3 8> DUMP: mapping (Pass II) [directories] 

09:24:43> DUMP: mapping (Pass II) [directories] 

09:24 :48> DUMP: estimated 198338 blocks (96.84MB) 

09:24:5 1> DUMP: dumping (Pass III) [directories] 

09:25 :06> DUMP: dumping (Pass IV) [regular files] 

09:29:55> DUMP: 78.26% done, finished in 0:01 

09:3 1 :16> DUMP: level 4 dump on Thu Nov 10 09:22:04 1994 

09:31:16> DUMP: 1 96698 blocks (96.04MB) 

09:31:17> DUMP: DUMP IS DONE 

09:31 :18> Backup command completed successfully. 

09:3I:24> 

09:3 1 :24> Request Statistics: 
09:3 1 :24> Data written : 98400 KB 
09:3 1 :24> Elapsed time : 00:09:32 
09:31:24> Status : Successful 
09:31:24> Performance : 172 KB/sec 
09:31:24> Peak rate : 315 KB/sec 
09:31:25> Write Retries: 123 

09:31:25> — - 

09:3 1 :25> =====:=^= == = 


09:31:25> Close Volume 

09:3 1 :25> Writing a trailer to end of data 

09:33 :07> Close Media Server 

09:33 :07> Start merges 
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From: vant [vanthof@hestia] 

Sent: Thursday, November 10, 1994 3:50 PM 

To: 'sysadmin@hestia' 

Cc: 'Dave Van't Hof ; 'Thomas Laidig'; 'Mark Hofmann'; Tim B. Robinson' 
Subject: rexec problems? 


Hi, 

I believe I've stumbled across some difference between rexec and rsh and 
the result is that rexec dies. Here's the command line: 

rexec hestia "(cd /n/hestia/s3/dracjobs/drc; Ai/chipftools/bin/vlsimm -I -t -n -f local_f.imml -p . -p yimmlayouts - 
V /n/rama/s4/vanthof/compass/mobi/euterpe/vIsi.boo -o drc=mobiecUum.errl mobieclium >& run_imml. hestia. log])" 

and I get this: 

sh: run_imml.hestia,logl: bad number 

When I change the rexec to rsh, it works fine. I may have a typo in the above 
line, but I can't seem to find it. 

Any help would be greatly appreciated. 

Tlianks, 
Dave 


Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, Inc. 

"What rolls down stairs, alone or in pairs, rolls over the neighbor's dog? 

What's great for a snack and fits on your back? It's log, log, log!" 

LOG fh)m BLAMMO! (tm) All kids love Log! #incluce <std_disclaim.h> 
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From: Eric Murray [ericm@MicroUnity.conn] 
Sent: Thursday, November 10, 1994 4:29 PM 
To: Vant' 

Cc: 'sysadmin@MicroUnity,com'; Vanthof@MicroUnity.com'; 'tom@MicroUnity.com'; 
'hopper@MicroUnity.com'; 'tbr@MicroUnity.com' 

Subject: Re: rexec problems? 

vant wrote: 

> 

> 

>Hi, 

> 1 believe I've stumbled across some difference between rexec and rsh and 

> the result is that rexec dies. Here's the command line: 

> 

> rexec hestia "(cd /n/hestia/s3/dracjobs/drc; /u/chip/tools/bin/vlsimm -I -t -n -f local_f.imml -p . -p ./immlayouts - 

V /n/rama/s4/vantho£'compass/mobi/euterpe/vlsi.boo -o drc=mobieclium.errl mobieclium >& nm_imml.hestla.log I)" 
> 

> and I get this: 
> 

> sh: run_imml.hestia.logl : bad number 
> 

> When I change the rexec to rsh, it works fine. I may have a typo in the above 

> line, but I can't seem to find it. 


i can't duplicate this, i finally threw caution to the wind 
and ran this same command as you, and it worked fine. 

the only difference was that i ran it from dockmaster 
instead of hestia. 


ericm ericm@microunity.com 
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From: Graham Y. Mostyn [graham@thalia] 

Sent Thursday, November 10, 1994 8:02 PM 

To: 'woody@thalia'; 'tbr@thalia'; 'ras@thalia'; 'yves@thalia'; 'dane@thalia'; 'arya@thalia*; 

'noel@thalia'; 'biii@thalia'; 'rich@thalia'; 'tbe@thalja' 
Cc: 'hestia@thalia'; 'graham@thalia' 

Subject: Layout review 


Now that the main board layout is close to completion, we would like all of the circuit 
designers to check the final captured schematics and this interim layout, in particular 
tracing out the sections that they own. 

We're therefore circulating tomorrow (Friday) schematics and plots to the following 
people y and would appreciate it if you could report to Arya at or before the 3PM Monday 
netlist meeting of discrepancies in any of the three databases: 
SECTION DESIGNER 


DRAM, Euterpe, smart card woody, tbr 
Upstream transmitter ras 
Ch3/4 transmitter ras 
QPSK RX ras 
Audio yves 
Phone yves 
Video dane 
RF receivers arya 
Power planes noel. 
Power supplies noel 
IR noel 
VCOs, SAW osc. rich 
Mechanical compatibility tbe 


bill, graham 


Thcuiks for your help - the netlist meeting is held in the boxers ' 
conference room. 


Graham . 
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From: 


tbr 


Sent: 
To: 

Subject: 


Thursday, November 10, 1994 9:30 PM 
'hopper' 

forwarded message from Don Rozenberg 


Follow Up Flag: Follow up 
Flag Status: Red 

Start of forwarded message 

Status: RO 

X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] 

["7688" "Wed" "9" "November" "94" "8:58:26" "PST" "Don Rozenberg" "rozen@mercuiy " nil "188" "SUNFLASH! 
(SMCC Intros hyperSPARC SPARCstation) (fwd)" "'^From:" nil nil "U"]) 
Return-Path: <rozen@mercury> 

Received: from mercury.microunity.com by gaea.microunity.com (4.1/musel.3) 

id AA14357; Wed, 9 Nov 94 08:56:53 PST 
Received: from localhost by mercury.microunity.com (8.6.4/muse-sw.2) 

id IAA04263; Wed, 9 Nov 1994 08:58:26 -0800 
Message-Id: <19941 1091658.IAA04263@mercuryjnicrounity.com> 
X-Mailer: ELM [version 2.3 PLl 1] 
From: rozen@mercury (Don Rozenberg) 
To: tbr@mercury (Tim Robinson), admin@mercury 
Subject: SUNFLASH! (SMCC Intros hyperSPARC SPARCstation) (fSvd) 
Date: Wed, 9 Nov 94 8:58:26 PST 


Forwarded message: 

> From gavin@acclaim.com Wed Nov 9 08:07:57 1994 

> Date: Wed, 9 Nov 94 07:24: 1 1 PST 

> Message-Id: <941 1091 524.AA09782@acclaim.com> 

> X-Sender: gavin@aspen 

> X-Mailer: Windows Eudora Version 2.0.3 

> Mime- Version: 1 .0 

> Content-iype: texfplain; charset="us-ascii" 

> To: rozen@MicroUnity.com 

> From: uusr945!uupsi2!Corp.Sun.COM!Edgar. Vaughan@rambone.psi.net (Edgar Vaughan) (by way of 
gavin@acclaim.com (Gavin Thames)) 

> Subject: SUNFLASH! (SMCC Intros hyperSPARC SPARCstation) 

> Cc: ericm@MicroUnity.com 


Hi. 


This is came firom Gavin. It is the first piece of information 
about the Sun Aimouncement. I am sure that there will be more. 


Don 


> 


> Hello Don, 


> 


> Here is the marketing hype that has been disfributed at this time. 

> I have not received upgrade or detailed pricing information. 

> I should receive it sometime today. I'll keep you posted. 


> 


> Thanks, 


> Gavin 

> Acclaim Technology Inc. 
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> FYI 

> 

> 

> JJJ J J J J Jim Chabrier, (415) 336-0317 

> _/ _/ _/_/_/ _/ Ed Vaughan, (415) 336-2238 

> JJJ J J J J J 

> J J J J J J 

>JJJ JJJ J J MSUPALOl-451 

> 2550 Garcia Avenue 

> Mountain View, CA 94043 
>MICROSYSTEMSFax: (415)336-0822 

> 

> Jim Chabrier ~ Jim.Chabrier@Corp.Sun.COM 

> Ed Vaughan ~ edgar.vaughan@Corp.Sun.COM 

> 

> TERRITORY COVERAGE: 

> 

> Jim Chabrier -- Sunnyvale, Mountain View, Palo Alto, Belmont, San Carlos, 

> Menlo Park, Redwood City, Burlingame, Brisbane, South 

> San Francisco. 

> 

> TBH ~ Santa Clara, Fremont, Milpitas, Cupertino. 
> 

> Ed Vaughan — San Jose, Campbell, Los Gatos, Saratoga, Los Altos, Scotts 

> Valley, Santa Cruz County, and Monterey County. 


> -+This message has been approved for distribution to this alias+- 
> 

> 

> The following announcement was made earlier today, Nov. 8, 1994 

> by SMCC. If you have any questions regarding this announcement, 

> please contact Chris Scheufele of SMCC Product Marketing at 

> (415) 336-1299. Please direct all press inquiries to Gayle 

> Jennings of SMCC Public Relations at (415) 336-0787. 
> 

> 

> SMCC INTRODUCES HYPERSPARC SPARCstation 

> 

> New SPARCstation 20 Model Optimized for Floating Point 

> and Cache MemoryPerformance 
> 

> MOUNTAIN VIEW, Calif, November 8, 1 994 - Sun Microsystems 

> Computer Company (SMCC) today continued to enhance the industry's most 

> successful high-end workstation family, the SPARCstation(TM) 20, by 

> introducing a new model, the SPARCstation 20 Model HSl 1. The new 

> workstation is aimed at compute-intensive technical applications where 

> the system's floating-point performance and cache memory architecture 

> are an advantage. Among these applications are simulation, electronic 

> design, modeling and analysis. 
> 

> SMCC's SPARCstation 20 Model HS 1 1 uses the new 100 MHz 

> hyperSPARC(TM) processor from ROSS Technology, Inc. It is supported by 

> the Solaris(TM) 2.4 software environment and by a new release of the 

> Solaris 1 software environment, called Solaris 1.1.2. The new 
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> SPARCstation 20 Model HSl 1 joins SMCC's highly successful SPARCstation 

> 20 Model 61 at the high end of SMCC's SPARCstation 20 family. The new 

> SPARCstation 20 Model HSll is rated at 104.5 SPECint92 and 127.6 

> SPECfp92. 

> 

> "At Sun, we stress the use of open technologies. Our open 

> business model allows us to take the best technology available at a 

> given time and apply it to the needs of our customers. SPARC(R) 

> technology is an example," said Jay Puri, vice president of product 

> marketing at SMCC. "By using hyperSPARC in the new Model HSl 1, we have 

> responded to those customers whose applications can take advantage of 

> the floating-point performance offered by the ROSS processor and 

> delivered a workstation to match their needs." 
> 

> The new SPARCstation 20 model HS 1 1 is built on the familiar 

> "pizza box" package of all SPARCstation 20 workstations, providing the 

> kind of expandability customers have come to expect: up to 512 

> megabytes of main memory, up to 2 gigabytes of internal mass storage, 

> and four SBus slots. The workstation also includes a CD-ROM drive, 

> 3.5-inch floppy disk drive and high-quality audio. The SPARCstation 20 

> Model HSl 1 is binary compatible with existing applications. 
> 

> Further, SPARCstation 10 and SPARCstation 20 workstation and 

> server customers whose applications can benefit from the hyperSPARC 

> architectural features can upgrade their systems with 100 MHz 

> hyperSPARC modules. 

> 

> "The SPARCstation 20 family is the highest volume, most widely 

> supported high-end workstation line in the industry," Puri said, "With 

> the Model HSl 1, the SPARCstation 20 family continues to be the industry 

> value leader." 

> 

> Strong Software Environment Support 

> 

> Operating system support comes from the Solaris 2.4 and from 

> the enhanced Solaris 1 .1 .2 software environments. With the Solaris 

> 1.1.2 release. Sun continues its focus on quality operating 

> environments. Additionally, the Installation time of Solaris 1.1.2 has 

> been reduced by as much as 25 percent. Full compatibility is maintained 

> with previous Solaris 1 releases. Further, Solaris 1.1.2 supports all 

> SMCC SPARC systems supported by previous releases of Solaris 1, in 

> addition to the new hyperSPARC upgrade modules. 
> 

> Pricing and Availability 

> 

> The SPARCstation 20 Model HSl 1 is available in a base 

> configuration with 32 megabytes of memory, 1 gigabyte of mass storage, 

> and a 17-inch TurboGX(TM) color monitor, for $18, 695. It will be 

> available December, 1994, 
> 

> Solaris 1. 1 .2 is available now for the United States. A 

> European (French, German, Italian and Swedish) version will be 

> available in December. Versions for Japan, Korea, PRC and Taiwan will 

> be available in January. 
> 

> Sun Microsystems Computer Company (SMCC), the world's top 

> supplier of open network computing solutions, is an operating company 

> of Sun Microsystems, Inc. Built on Sun's legacy of "The Network is the 

> Computer(TM)," SMCC's SPARC(R)/Solaris(TM) workstation and server 

> family leads the UNIX(R) market. The company has its headquarters in 

> Mountain View, Calif. 
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> 

> ### 

> 

> (c) 1994 Sun Microsystems, Inc. Sun, the Sun logo, Sun Microsystems, 

> The Network is the Computer, TurboGX and Solaris are trademarks or 

> registered trademarks of Sun Microsystems, Inc. All SPARC trademarks, 

> including the SCD Compliant logo, are trademarks or registered 

> trademarks of SPARC International, Inc. SPARCstation is licensed 

> exclusively to Sun Microsystems, Inc. hyperSPARC is licensed 

> exclusively to ROSS Technology, Inc. Products bearing SPARC trademarks 

> are based on an architecture developed by Sun Microsystems, Inc. ROSS 

> is a registered trademark of ROSS Technology, Inc. UNIX is a registered 

> trademark of Novell, Inc., in the United States and other countries, 

> exclusively licensed through X/Open Company, Ltd. All other product or 

> service names mentioned herein are trademarks of their respective 

> owners. 
> 

> Press announcements and other information about Sun Microsystems are 

> available on the Internet via the World Wide Web. Type 

> http://w w w . sun .com , using the Mosaic tool. 
> 

> 
> 


> End Included Message - 

> 
> 
> 


Don Rozenberg 

MicroUnity Systems Engineering, Inc. 
255 Caspian Drive, Sunnyvale, CA 94089 
(408) 734-8100 FAX (408) 734-8136 
End of forwarded message 
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Subject: 


To: 


Sent: 


From: 


tbr 

Thursday, November 10, 1994 10:28 PM 
'Wayne Freitas* 

swag dates for Euterpe and Caiiiope 


Follow Up Flag: Follow up 
Flag Status: Red 


Wayne Freitas wrote (on Wed Nov 9): 


Tim I've been updating the bring-up schedule and could really use a better guess 
than mine of when Calliope and Euterpe might be available. Would you care to 
provide a swag? 

Calliope is entirely in the hands of the Gods (ie Al!). As for 
Euterpe, we have the baseplate fractured, and as of Wednesday 
we hit a roadblock in getting it to route. My best guess is we won't 
be ready to cut masks for at least 4 weeks. Recon 4 weeks to get the 
last mask back after that. If the process is fully up within the next 
month, we might expect them to process wafers as the masks come in. 
So first chips could be out a week or so after that. That would be 9 
weeks from today. 


Tim 
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From: tbe@MicroUnity.com 

Sent: Friday, November 11 , 1 994 2: 1 9 AM 

To: Tim B. Robinson' 

Cc: 'noel@MicroUnity.com'; 'pniayei"@MicroUnity.com'; 'jt@MicroUnity.com' 
Subject: Re: pcb status 

Tim Robinson wrote: 
> 

>There was a rather alarming message earlier from yves about taking the 
>SDRAMs off the ground plane, which I assume was something also 
>discussed at this meeting. I have a major problem with that, since it 
>would mean the return path for the transient currents would have a huge 
>loop back to the PSU and we would have serious ground bounce problems. 
>I have no problem splitting the euterpe and calliope planes if we can 
>find room to do it, but separating euterpe and the DRAMs with Ins edge 
>rate TTL signals between them would be a big disaster. I agree it 
>seems we still have a way to go. 
> 

>Tim 

Noel and I had to leave the meeting after the mechanical discussion--] 
didn't hear of this while there. It does not sound right, I agree. 

-Tom 


Tom Eich | tbe@microunity.com 

MicroUnity Systems Engineering, lnc.| 
255 Caspian Dr. Sunnyvale, CA 94089 | 
(408)734-8100, (408)734-8136 fax | 
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From: 


tbr 


To: 
Cc: 

Subject: 


Sent: 


Friday, November 11, 1994 2:23 AM 
'tbe@MlcroUnity.com' 
'jf; 'noel'; 'pmayer' 
pcb status 


Follow Up Flag: Follow up 
Flag Status: Red 

tbe@MicroUnity.com wrote (on Fri Nov 1 1): 

Pattie and I spoke earlier today about the schedule to complete the first 
pcb. We are concerned that the Monday deadline may not be met no matter 
how many hours she (or I) put in this weekend, due to the many features yet 
to be added. 

Tim may not be aware that when we had the meeting yesterday with the EMI 
test lab President, the chassis to pcb grounding and individual analog 
circuit shield grounding was discussed extensively. There seemed not to be 
any clear, common understanding of the problem prior to this meeting, and 
we ended up picking this guy's brains to determine a strategy, driven by 
Wayne. (Not sure that this person is a bad person to mm to for such 
advice, but the advice greatly increased the scope of pcb work from what I 
expected [chassis ground to analog grounds at many points. Btw, I expect 
to hear from Richard Mueller next week on same subject— blinders on for 
now.). We took the decision to interpose partial chassis ground planes 
beneath the shielded analog circuit elements and tie them to the shield 
wall traces with many vias. This with the local supply lines interspersed. 

In addition, for lighting and ESD testing, we need to make certain we have 
adequate chassis ground pass through to avoid dumping spikes into the pcb 
ground plane. Other things not yet addressed as far as I know are DC 
bussing from the RO pins (Noel update if defined), and numerous other 
details. Bottom line is Pattie and I are concerned about meeting the 
monday deadline and want to keep you informed of the latest developments. 
Let's discuss. 

There was a rather alarming message earlier from yves about taking the 
SDRAMs off the ground plane, which I assume was something also 
discussed at this meeting. I have a major problem with that, since it 
would mean the retum path for the transient currents would have a huge 
loop back to the PSU and we would have serious ground bounce problems. 
I have no problem splitting the euterpe and calliope planes if we can 
find room to do it, but separating euterpe and die DRAMs with Ins edge 
rate TTL signals between them would be a big disaster. I agree it 
seems we still have a way to go. 


Tim 
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From: vant [vanthof@hestia] 

Sent: Friday, November 11,1 994 8:30 AM 

To: 'Tom Vo' 

Cc: 'Dave Van't Hof ; 'Mark Hofmann'; Tim B. Robinson'; 'Lisa Robinson'; 'Geert Rosseel' 

Subject: euterpe Ivs finished 


Hi Tom, 

The euterpe Ivs finished. The resulst are in 

/u/vanthof /compass/mobi/euterpe/tapeout/euterpe . compare 

There are about 300 devices unmatched. A quick glance through the file shows some 
problems with CELOW_0, CEHIGH_0, VRR34_0 -> VRR3 5_0, VRR54_0 -> VRR55_0, some pll signals, 
etc. There are a few gates which have a schematic signal called XIOBYTEl-X2P_l-X4P_l-XlP_ 
1-LOGICO_OP and the layout is tied to VDDI . 

In addition to the mismatches, there are 96 extra schematic devices. 

The output file is only 1.3MB. If you need any. help, please let me know. 

Thanks , 

Dave 

Dave Van't Hof vanthof@microunity . com MicroUnity Systems Engineering, 
Inc . 

"What rolls down stairs, alone or in pairs, rolls over the neighbor's dog? 

What's great for a snack and fits on your back? It's log, log, logl" 
LOG from BLAMMO! (tm) All kids love Logl #incluce 
< std_disclaim . h> 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Alan Corry [agc@aphrodite] 

Friday, November 11, 1994 9:46 AM 

'abbott (Curtis Abbott)* 

'Bob Sutherland' 

Re: a couple of questions 


> 


> we've just had a big review meeting on QAM, Calliope , etc., to bring 

> the new DSP people up to speed, a couple questions came up for you: 
> 

> - the original digital rotator was controllable in pi/128 steps. is 

> that still the case with the IQ balance fix? 

> 

Yes, still the same. The change here was more to do with whether you can bypass the 
rotator or not (you used to be able to, now you can't) . Though you can turnoff the IQ 
balancer . 

> - does the IQ balance circuitry maintain 10 -bit arithmetic throughout? 
> 

Not an easy question to answer since there are multiple precisions used. 

The multiplier used is an 8x10 parallel unit. The input data from the DACs is 8-bit that 
is rotated (using a 10-bit SIN/COS value) . The multiplier is truncating to a 10-bit 
result. The LMS coefficients are accumulated to 20-bit accuracy and the most significant 
8 -bits are used in the adaption algorithm. 
The eventual result is presented at 10-bits. 

I believe ras has simulated the adaptive filter using these quantizations to check for 
precision effects, brian began work on verifying the verilog which would have included 
checking to ensure that there were no unexpected quantization problems with the real 
hardware but was pulled off to work on euterpe. 
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From: Eric Murray [ericm@MicroUnity.com] 
Sent: Friday, November 11. 1994 10:01 AM 
To: 'sysaclm@MicroUnity,com' 
Subject: disk usage report 

For directories over 100 megs: 
usef s info: 


brianl 

1412 

hopper 

1229 

chip 

1028 

dickson 

907 

fwo 

889 

craig 

883 

geert 

847 

jsw 

684 

tbr 

661 

gmo 

577 

rozen 

575 

vanthof 

559 

brendan 

479 

vijay 

477 

sandeep 

472 

h 

464 

rocky 

449 

qua 

436 

brian 

417 

wampler 

370 

the 

353 

ken 

338 

khp 

291 

age 

282 

fur 

281 

doi 

272 

torn 

268 

hchu 

258 

hessam 

239 

ras 

239 

veena 

225 

fling 


iimura 

211 

peter 

206 

bill 

205 

cox 

201 

jefirn 

197 

rich 

195 

haim 

190 

lisar 

189 

mws 

185 

al 

181 

billz 

174 

Vandyke 

173 

ericm 

172 

solo 

169 

bpw 

156 

gregg 

152 

guarino 

151 
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146 

randy 

142 

wingard 

140 

karzes 

139 

woody 

138 

chuck 

137 

jeff 

135 

dane 

132 

hayes 

132 

octtools 

130 

albers 

128 

tomho 

127 

kgk 

123 

warren 

123 

mikew 

119 

fambro 

119 

yves 

116 

ong 

112 

paulb 

103 

lanyk 

102 


packages info: 
chip-euterpe-buil 2029 
calliope 1579 
news 1335 
euterpe- verify 1011 
chip-archive 869 
orchis_snap 811 
chip-proteus 793 
calliope-disk2 730 
soft-src 639 
cadence 636 
losf-build 614 
ptolemy 614 
archives 598 
sun 568 
cadence, hp 552 
calliope 1 -fractur 487 
chip-calliope 484 
soft 477 
chip-terpsichore 475 
sgi 377 
xl Ir5_ken_p26 329 
castor-retry 325 
bosf-build 323 
chip-archive-terp 318 
calliope-overflow 297 
mips-4.52 282 
osf 260 
chip-arch ive-mn em 259 
bigtmp 239 
Xllr4 228 
bsd 222 
cadence_doc 221 
synopsys 216 
cadence_doc_9402 215 
budtooldb 190 
budtool 181 
Motif 177 
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mechanica 

164 

sgi5 

152 

ucberl 

147 

vlsi.v8r4_2 

145 

ikos 

144 

proe tmp 

138 

ftp 

134 

khoros 

134 

proe_13.0 

134 

c^liope-verify 

132 

iunura.be 

128 

gnu 

125 

bsd43 

115 

frame-4.0.3 

114 

svr4 

114 

XllrS 

111 

lib 

106 

iimura-cross 

106 

chip-mdunit 

105 

motif 1.2 

101 


macKine user megs package megs total megs max capaci^ % used 

auspex 19878 18775 38653 59499 64% 

rama 3676 2336 6012 9428 63% 

rhea 215 1599 1815 2484 73% 

gaea 5 1718 1723 1780 96% 

cronus 626 2217 2843 6208 45% 

auspex rama rhea gaea cronus: 

24400 26645 51046 79399 64% 
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From: Jay Tomlinson [woody @luckboy] 
Sent: Friday, November 11,1 994 1 0:39 AM 
To: 'Lisa Robinson' 
Cc: 'tbr@lucl<boy' 
Subject: liermeseasy 

Lisar, 

I think the problem is that you are enabling the channel in hcO. This leaves 
iorateO still disabled. 

Something else might also incorrect smce iodinAO goes to zero slightly after 
dinO starts changing, but iodinBO (iobyteO to iorate) is always X. I don't yet 
know what is causing this behavior, I need to go learn more about iorate. 

Jay 

Lisa Robinson wrote (on Fri Nov 1 1): 


There is a smaller dump in 
/n/rhodan/s3/euterpe/verilog/bsrc/henneseasy_V.* 


Lisa R. 
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From: 
Sent: 
To: 

Subject: 


abbott 

Friday. November 11, 1994 11:12 AM 
'puri' 

forwarded message from Alan Corry 


Manoj - concerning Alan's last paragraph, what was the precision of your simulations? 
- Curtis 

Start of forwarded message 

From: agc@aphrodite {Alan Corry) 
To: abbott (Curtis Abbott) 
Cc: rasOaphrodite (Bob Sutherland) 
Subject: Re: a couple of questions 
Date; Fri, 11 Nov 94 7:46:02 PST 


> we've just had a big review meeting on QAM, Calliope, etc., to bring 

> the new DSP people up to speed. a couple questions came up for you: 
> 

> - the original digital rotator was controllable in pi/128 steps. is 

> that still the case with the IQ balance fix? 
> 

Yes, still the same. The change here was more to do with whether you can bypass the 
rotator or not (you used to be aible to, now you can't) . Though you can turnoff the IQ 
balancer . 

> - does the IQ balance circuitry maintain 10-bit arithmetic throughout? 

Not an easy question to answer since there are multiple precisions used. 

The multiplier used is an 8x10 parallel unit. The input data from the DACs is 8-bit that 
is rotated (using a 10 -bit SIN/COS value) . The multiplier is truncating to a 10-bit 
result. The LMS coefficients are accumulated to 20-bit accuracy and the most significant 
8 -bits are used in the adaption algorithm. 
The eventual result is presented at 10-bits. 

I 'believe ras has simulated the adaptive filter using these quantizations to check for 
precision effects, brian began work on verifying the verilog which would have included 
checking to ensure that there were no unexpected cjuantization problems with the real 
hardware but was pulled off to work on euterpe. 


End of forwarded message 
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From: 
Sent: 
To: 

Subject: 


Kurt Warn pier [wampler@thoas] 
Friday, November 1 1 , 1 994 1 1 : 1 8 AM 
'geert@ambiorix' 
Re: GARDS 


> Hi Kurt 
> 

> All the data lives in /n/ghid.ra/s3/geert/euterpe/verilog/bsrc . 
> 

> I did not change anthing in the Makef ile . tst, but I added a set of 
>comment lines in the routing strategy section. Re - ar r angning the 
order of this section should give you what you want. 


OK - I got a snapshot copy of all the files. I'll keep you informed of 
any progress. 


> 


> 


Geert 


- Kurt 
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From: Jean-Yves Michel [yves@thalia] 

Sent: Friday, November 11,1 994 1 1 :34 AM 

To: 'tbr@aphroclite' 

Cc: 'liestia@thalia' 

Subject: Re: SDRAM power 


Tim Robinson wrote: 
> 

> Jean- Yves Michel wrote (on Thu Nov 10) : 
> 

> It was decided during an earlier meeting that the SDRAM will be 
powered 

> directly from the DC/DC converter, not using the power planes, in 
order 

> to reduce the supply noise . 
> 

> Please clarify when that was decided. It's not acceptable to have the 

> SDRAM off the plane. It absolutely has to have good decoupling. No 

> one puts DRAM on anything other than solid ground and power planes, 
> 

> Because of possible radiated noise too 

> (the distance from SDRAM to DC/DC is a 500MHz 1/4 wave) ^ we are 

> planning to use the INT 1 layer (in-between the ground plane and the 

> component layer) . The power bus will be made of 12 94 mils wide 
lines, 

> alternating power and ground return, 6 mils apart. There will be 2 
ground 

> shields on both sides and a ground plane on the component side. 
> 

> Do you agree with this scheme? 
> 

> Absolutely not. 

OK with me for the power planes. 

What about using the 2 INT layers to make special power planes for the SDRAM' s? 

But before going further, I think we need to re-visit the amount of noise the SDRAM will 
inject into the power delivered to Euterpe and Calliope using the L- shape power plane 
layout. I unfortunately don't have all the data for that. 

Could you give me a rough estimate of the supply current characteristic for the SDRAM 
being accessed. 

For Euterpe and Calliope, we have been using 2A current spikes at 1.2GHz, 300ps wide. Is 
it OK? 

> Following advices from our EMi/FCC consultant, do we have enough 

> reservoir capacitances around the SDRAM 's to guarantee an acceptable 

> ripple . 

> 

> What is the acceptable ripple? 
> 

I will re-calculate the acceptable ripple for analog Calliope. I takes into account the 
noise frequency (lOOMHZ + odd harmonics from SDRAM) , the amount of decoupling on the 
digital and the analog side and the series impedance of the L- shape power plane. 

Jean -Yves 


Exhibit C8 


Page 332 of 5 


From: Jay Tomlinson [woody@luckboy] 
Sent: Friday, November 1 1 . 1 994 1 2: 1 3 PM 
To: 'Lisa Robinson' 
Cc: •tbr@luckboy' 
Subject: hermeseasy 

Lisar, 

The problem is that cIkinO_N and dinO_M are not driven. 
Jay 

Lisa Robinson wrote (on Fri Nov 11): 


There is a smaller dump in 
/n/rhodan/s3/euterpe/verilog/bsrc/henneseasy_V.* 


Lisa R. 
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From: Jean-Yves Michel [yves@thalia] 
Sent: Friday, November 11 , 1 994 12:20 PM 
To: 'tbr@thalia' 
Subject Re: SDRAM power 


Begin Included Message 

>From yves Fri Nov 1 1 09:33:40 1994 
Date: Fri, 11 Nov 1994 09:33:31 -0800 
From: yves (Jean-Yves Michel) 
To: tbr@aphrodite 
Subject: Re: SDRAM power 
Co: hestia 

Content-Length: 1969 

Tim Robinson wrote: 
> 

> Jean- Yves Michel wrote (on Thu Nov 10): 
> 

> It was decided during an earlier meeting that the SDRAM will be powered 

> directly from the DC/DC converter, not using the power planes, in order 

> to reduce the supply noise. 
> 

> Please clarify when that was decided. It's not acceptable to have the 

> SDRAM off the plane. It absolutely has to have good decoupling. No 

> one puts DRAM on anything other than solid ground and power planes. 
> 

> Because of possible radiated noise too 

> (the distance from SDRAM to DC/DC is a 500MHz 1/4 wave), we are 

> planning to use the INT 1 layer (in-between the ground plane and the 

> component layer). The power bus will be made of 12 94 mils wide lines, 

> alternating power and ground return, 6 mils apart. There will be 2 ground 

> shields on both sides and a ground plane on the component side. 
> 

> Do you agree with this scheme? 
> 

> Absolutely not. 

OK with me for the power planes. 

What about usmg the 2 INT layers to make special power planes for 
the SDRAM's? 

But before going further, I think we need to re-visit the amount 

of noise the SDRAM will inject into the power delivered to Euterpe and Calliope 

using the L-shape power plane layout. I unfortunately don't have all 

the data for that 

Could you give me a rough estimate of the supply current characteristic 
for the SDRAM bemg accessed. 

For Euterpe and Calliope, we have been using 2A current spikes at 1 .2GHz, 
300ps wide. Is it OK? 

> Following advices from our EMI/FCC consultant, do we have enough 

> reservoir capacitances around the SDRAM's to guarantee an acceptable 
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> ripple. 

> 

> What is the acceptable ripple? 
> 

I will re-calculate the acceptable ripple for analog Calliope. I takes 
into account the noise frequency (lOOMHZ + odd harmonics from SDRAM), the 
amount of decoupling on the digital and the analog side and the series 
impedance of the L-shape power plane. 

Jean-Yves 


End Included Message 
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From: 
Sent: 
To: 

Subject: 


Nsa 

Friday, November 11, 1994 12:26 PM 
'software-checklns-dist' 
gnu-tools/sim/terp memory, h memory.c 


U^jdate of /p/cvsroot /gnu-tools/sim/terp 

In directory calliope: /N/auspex/root/sS/lisa/src/gnu-tools/sim/terp 

Modified Files: 

memory . h memory , c 
Log Message: 

Removed move- engine code. 
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From: 
Sent: 
To: 

Subject: 


Bruce Bateman [stick@kephalos] 

Friday, November 11, 1994 1:13 PM 

'euterpe@kephalos' 

resistor code change from 5 to 6 


I now understemd that it has been decided to change the resistor code on euterpe from a 
value of 5 to 6. Although I haven't seen any discussion of this decision, I assume it is 
to help meet the speed targets. However, I should point out that the custom blocks, and 
particularly the cache were designed at resistor code = 5 and were not simulated at higher 
values. While I don't have particular concerns regarding functionality, I should point 
out that at least in the cache, power bus wiring was extremely tight and that the currents 
used for sizing the busses for IR drops and more importantly for electro-migration were 
based upon a resistor code of 5. 

Increasing the code to 6 will likely cause some power busses to exceed their EM limits by 
the percentage power increase (2 0%?) . 


BB 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Tom Laidig [tom@cIiol 

Friday, November 11, 1994 1:18 PM 

'Bruce Batsman' 

'euterpe@kephaios' 

Re: resistor code change from 5 to 6 


Bruce Bateman writes: 

I now understand that it has been decided to change the resistor code 
on euterpe from a value of 5 to 6 . Although I haven't seen any 
discussion of this decision, I assume it is to help meet the speed 
targets. However, I should point out that the custom blocks, and 
particularly the cache were designed at resistor code = 5 and were not 
simulated at higher values. While I don't have particular concerns 
regarding functionality, I should point out that at least in the cache, 
power bus wiring was extremely tight and that the currents used for 
sizing the busses for IR drops and more importantly for 
electro-migration were based upon a resistor code of 5 . 

Increasing the code to 6 will likely cause some power busses to exceed 
their EM limits by the percentage power increase (20%?) . 

I don't think there's any plan to change the resistor code for the caches or any other 
custom block. The problem is that the logic doesn't fit in the sofa, and bumping the 
power level up should help reduce gate size. 

It is a defect of our current methodology that ged2 spice has a resistor code built in, and 
that much of our analysis (both manual and 

automated) is based on a value hard- coded into a program. This really should be changed. 


Tom L 
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From: 
Sent: 
To: 

Subject: 


Geert Rosseel [geert@ambiorix] 
Friday, November 11, 1994 1:40 PM 
'hardheacls@ambiorix'; 'hestja@amblorix' 
IMMINENT DECISION : Euterpe SOFA Power 


Hi, 


In order to make the euterpe logic fit on the 10x10 die, we have to increase the power 
of the SOFA area with 20%. 

This will give all our gates a higher drive capability and therefore we can use smaller 
gates for the sarae drive . 

We are currently rebuilding the library and after that, we'll run a set of experiments. 
If the results are good, this will become a FINAL decision. We'll know the results in 
about a week. 


Geert 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Rich McCauley [rich@pegasus] 
Friday, November 11, 1994 2:25 PM 
'geert@annbiorix' 
'hardheads@pegasus' 

Re: IMMINENT DECISION : Euterpe SOFA Power 


This seems to be a reasonable course to follow for the main sofa. However, I would 
strongly prefer to remain at rcd=5 for the gardswarts (those that already exist eind ones 
in the future ) since they are very small anyway and having the extra margin is of great 
benefit. What's needed is of course a set of timing files for rcd=5 and rcd=6 or at the 
very least a multiplier that could be applied to timing numbers ( ignoring for the moment 
that there may not be a universal fudge factor ) . In principal it seems reasonable to 
have this available since how do we cover the situation of having different chips 
potentially at two different red values? 


> From geert®ambiorix Fri Nov 11 11:40:28 1994 

> Date: Fri, 11 Nov 1994 11:40:12 -0800 

> From: geertdambiorix (Geert Rosseel) 

> To: hardheads@ambiorix , hestia@ambiorix 

> Subject: IMMINENT DECISION : Euterpe SOFA Power 

> Content -Length: 506 


> 

> Hi. 


> In order to make the euterpe logic fit on the 10x10 die, we have to 

> increase the power of the SOFA area with 20%. 

> This will give all our gates a higher drive capability and therefore 

> we can use smaller gates for the same drive. 
> 

> We are currently rebuilding the library and after that, we'll run a 

> set of experiments. If the results are good, this will become a PINAL 

> decision. We'll know the results in about a week. 


rich 


> 


> 


> 


Geert 


> 


> 


> 


> 
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From: 
Sent: 
To: 

Subject: 


Tim B. Robinson [tbr@aphrodite] 
Friday, November 11 , 1994 2:40 PM 
'euterpe@aph rod ite' 
forwarded message from tbr 


one or two people seem not to have seen this for some reason though it was originally 
posted to Euterpe on Nov 6. 

Start of forwarded message 

To ; euterpe 

Subject: DECISION: event daemon 


The following is a description of what is being implemented for the Event Daemon register. 

A fixed Hermes sequence ID of 7 will be used for blocking reads. This sequence id will 
not be available for normal operations, but multiple blocking reads to different devices 
on the same ring can be outstanding simultaneously, each with sequence ID 1 , distinguished 
by the module address. Thus up to 7 normal operations and 4 blocking reads can be 
outstanding on each channel simultaneously. The collision detection which prevents 
multiple outstanding transactions to the same address in the same device will not apply to 
blocking reads. This is necessary because the conflict check is only approximate, looking 
at 6 low order address bits, and without this exclusion, normal operations could be held 
off pending a blocking read return. 

Stores to the Event Daemon register go via NB, so back to back stores from different 
threads to event registers in multiple devices is supported. The Event Daemon register is 
decoded from the "slow peripheral" queue, and communicates directly with the appropriate 
Hermes channel. It is thus possible for an Event Daemon store to be processed ahead of a 
normal load or store previously issued to the same Hermes channel. 

Hardware keeps track of pending blocking reads so duplicates can be suppressed. This 
deals with the problem of multiple blocking reads initiated by different threads after 
multiple interrupts to different threads have been returned together. Software therefore 
does not have to provide independent synchronization to ensure only one blocking read is 
posted. If an interrupt is permanently masked off in the Euterpe event register and there 
is a possibility that for some reason this interrupt causes the blocking read to return, a 
deadlock can be avoided by having a watchdog routine periodically issue another blocking 
read. 

Software is still responsible for posting at least one blocking read for each interrupt 
received. ie there is no automatic hardware rescheduling of blocking reads. There is a 
possibility of duplicate events being signaled if another blocking read is issued by 
another thread before bits have been cleared in the peripheral device event register. 
This can be mitigated by always clearing the peripheral device event register before the 
corresponding bits in the Euterpe event register. However, because of possible delays in 
processing the store over the Hermes channel, there may still be a race here. 
If so, software will have to be able to handle it. 

This implementation does not directly address the problem of a low priority interrupt 
return blocking a high priority interrupt up to the point where the new blocking read is 
issued. 


End of forwarded message 
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From: 
Sent: 
To: 

Subject: 


lisa 

Friday, November 11, 1994 2:47 PM 
'ken' 

file off of backup 


I tried to use "ausrestore" (aka budtool) to get a file off of backup, but the retrieval 
didn't work. After a half hour of looking at volume labels it found the right one, then 
said it was retrieving, and then complained that it couldn't open /dev/tty and couldn't 
create a directory in /tmp. I'm not sure what would cause such problems, but it seems 
that ausrestore isn't going to do it for me. The file I need is: 

/n/auspex/s6/lisa/src/gnu-tools/sim/terp/cerberus . c 
It should have been saved by last night's incremental backup. Could you either get the 
file for me, or tell me how I can do it myself? 


Thanks , 
lisa 
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From: Jean-Yves Michel [yves@thalia] 

Sent: Friday, November 1 1 , 1 994 3:23 PM 

To: 'tbr@thalia"; 'bill@thalia'; 'graham^thalia'; 'tom@thalia'; 'philip@thalia'; 'noel@thalia' 

Cc: 'hestia@thalia' 
Subject: hestia power planes 

Here is the latest proposal, pending a final OK from Tom and Philip on the pcb stack-up: 
we will have 2 seperate power/gnd planes, one for Euterpe and the SDRAM and one for 
Calliope and peripherals. The calliope planes will be L-shaped and the other one will be 
closer to a rectangle. 


. . calliope planes 

-- euterpe/SDRAM planes 


EUTERPE 

DC/DC 


3 . 3V GND 
X X 


There will be a small supply voltage difference between euterpe and calliope due to IR 
drop but the differential interface should not be affected. 

In order to have these 4 planes, we will have the following PCB stack -up: 


component .5oz 

26mils dielectric 
power 1 2oz 

2mils dielectric 
ground 1 2oz 

6mils dielectric 
ground 2 2oz 

2mils dielectric 
power 2 2ox 

26mils dielectric 
solder . 5oz 


outside the outlined area, the 4 internal layer will be used differently to carry power 
(3.3, 5 and 12V}, current carrying ground planes, shields and chassis ground planes. 

If you have any objection, raise your voice immediately. A lot of layout will be done this 
week-end, so the power plane scheme should be finalized by the end of the day. 

Jean- Yves 
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From: 
Sent: 
To: 

Subject: 


philip@microunity.com 

Friday. November 11, 1994 3:39 PM 

'Geert Rosseel'; 'harctheacls@ambiorix'; 'liestia@ambiorix' 

Re: IMMINENT DECISION : Euterpe SOFA Power 


what does this mean to the total power consumption (and therefore 

dissipation) of the euterpe chip? If most of the chip is SOFA, does this mean a 20% 
increase in overall chip power consumption? 


At 11:40 AM 11/11/94 -0800, Geert Rosseel wrote: 


> In order to make the euterpe logic fit on the 10x10 die, we have to 
>increase the power of the SOFA area with 20%. 

>This will give all our gates a higher drive capability and therefore we 

>can use smaller gates for the same drive. 

> 

> We are currently rebuilding the library and after that, we'll run a 
>set of experiments. If the results are good, this will become a FINAL 
>decision. We'll know the results in about a week. 


> Geert 


> 


Hi, 


> 
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From: philip@microunity.com 

Sent: Friday, November 11 , 1 994 3:52 PM 

To: 'Jean-Yves Michel'; 'tbr@thalla'; 'bili@thalia'; 'graham@thalia'; 'tom@thalia'; 'philip@thalfa'; 

'noel@thalia' 
Cc: 'hestia@thalia' 
Subject: Re: hestia power planes 


At 1:22 PM 11/11/94 -0800, Jean- Yves Michel wrote: 

>Here is the latest proposal, pending a final OK from Tom and Philip on 
>the pcb stack-up: 

>we will have 2 separate power/gnd planes, one for Euterpe and the SDRAM 
>and one for Calliope and peripherals. The calliope planes will be 

L- shaped 

>and the other one will be closer to a rectangle. 


.... calliope planes 
CALLIOPE . euterpe/ SDRAM planes 


DC/DC 


3 .3V 
X 


6ND 

X 


>There will be a small supply voltage difference between euterpe and 
>calliope due to IR drop but the differential interface should not be 
affected. 

> 

>In order to have these 4 planes, we will have the following PCB stack-up: 
> 

> component .5oz 

> 26mils dielectric 

> power 1 2oz 

> 2mils dielectric 

> ground 1 2oz 

> 6mils dielectric 

> ground 2 2oz 

> 2mils dielectric 

> power 2 2ox 

> 26mils dielectric 

> solder . 5oz 

> 

>outside the outlined area, the 4 internal layer will be used 
>differently to carry power (3.3, 5 cind 12V), current carrying ground 
>planes, shields 
and 

>chassis ground planes. 
> 

>If you have any objection, raise your voice immediately. A lot of 
>layout will be done this week-end, so the power plane scheme should be 
>finalized by the end of the day. 
> 

>Jean-Yves 
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HADCO, our usual PCB source, has sent their sales /tech resources out this week. The 
construction is not impossible (at first glance) although it seems that it will be more 
expensive as we will be using more of the non-standard 2 on 2 copper laminate. 

More next week. Go ahead and lay it out this weekend anyway. It is most likely a very 

marginal cost adder to our already expensive PCB. 

Of course, we can always console ourselves that we have not (yet) added any blind or 
buried vias . 

Philip Wong 
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From: tbr 

Sont: Friday, November 1 1 . 1 994 7:38 PM 

To: 'Jean-Yves Michel' 

Cc: 'hestia@thalia' 

Subject: Re: SDRAM power 

Follow Up Flag: Follow up 

Flag Status: Red 


Jean- Yves Michel wrote (on Fri Nov 11): 

Tim Robinson wrote: 

> 

> Jean-Yves Michel wrote (on Thu Nov 10): 
> 

> It was decided during an earlier meeting that the SDRAM will be powered 

> directly firom the DC/DC converter, not using the power planes, in order 

> to reduce the supply noise. 

> 

> Please clarify when that was decided. It's not acceptable to have the 

> SDRAM off the plane. It absolutely has to have good decoupling. No 

> one puts DRAM on anything other than solid ground and power planes. 

> 

> Because of possible radiated noise too 

> (the distance from SDRAM to DC/DC is a 500MHz 1/4 wave), we are 

> planning to use the INT 1 layer (in-between the ground plane and the 

> component layer). The power bus will be made of 12 94 mils wide lines, 

> alternating power and ground return, 6 mils apart. There will be 2 ground 

> shields on both sides and a ground plane on the component side. 
> 

> Do you agree with this scheme? 

> 

> Absolutely not. 

OK with me for the power planes. 

What about usmg the 2 INT layers to make special power planes for 
the SDRAlVTs? 

I think the main issue is keeping the SDRAMS and Euterpe on the same plane. 

But before going further, I think we need to re-visit the amount 

of noise the SDRAM will inject into the power delivered to Euterpe and Calliope 

using the L-shape power plane layout. I unfortunately don't have all 

the data for that. 

Could you give me a rough estimate of the supply current characteristic 
for the SDRAM being accessed. 

I cannot find waveforms in any of the databooks. But from experience 

I would say you should expect a spike of 50 - 100mA of a few ns 

duration during RAS precharge. I would be more worried about the I/O 

drivers which are switohing full 3V rail to rail with approx Ins edge 

rate into order 20pF We can have about 50 of these switching simultaneously. 
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For Euterpe and Calliope, we have been using 2A current spikes at 1.2GHz, 
300ps wide. Is it OK? 

Bill would have to comment on the amplitude and duration. However, 
the current target cycle time on Euterpe s 1 .08GHz (ie lOx the 54MHz 
reference), so it's contribution will not have the same spectrum as Calliope. 

> Following advices from our EMI/FCC consultant, do we have enough 

> reservoir capacitances around the SDRAM's to guarantee an acceptable 

> ripple. 
> 

> What is the acceptable ripple? 
> 

I will re-calculate the acceptable ripple for analog Calliope. I takes 
into account the noise frequency (lOOMHZ + odd harmonics from SDRAM), the 
amount of decoupling on the digital and the analog side and the series 
impedance of the L-shape power plane. 

SDRAM is likely to be running somewhat lower than I OOMHz because the 
vendors have not yet been able to make parts above 83MHz. 

We take the SOFA frequency 1080 and divide by an integer to get a 
frequency lower than but as close as possible to the maximum DRAM rate. 

Tim 
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From: Tim B. Robinson [tbr@thalia] 

Sent: Friday, November 1 1 . 1 994 7:38 PM 

To: 'Jean-Yves Michel' 

Cc: 'hestia@thalia' 

Subject: Re: SDRAM power 


Jean-Yve3 Michel wrote (on Fri Nov 11) : 

Tim Robinson wrote: 
> 

> Jean- Yves Michel wrote (on Thu Nov 10) : 

> 

> It was decided during an earlier meeting that the SDRAM will be 
powered 

> directly from the DC/DC converter, not using the power planes, in 
order 

> to reduce the supply noise. 
> 

> Please clarify when that was decided. It's not acceptable to have the 

> SDRAM off the plane. It absolutely has to have good decoupling. No 

> one puts DRAM on anything other than solid ground and power planes. 

> Because of possible radiated noise too 

> (the distance from SDRAM to DC/DC is a 500MHz 1/4 wave) , we are 
planning to use the INT 1 layer (in-between the ground plane and 


the 

> 

lines , 
> 

ground 


component layer) . The power bus will be made of 12 94 mils wide 
alternating power and ground return, 6 mils apart. There will be 2 
shields on both sides and a ground plane on the component side. 

> Do you agree with this scheme? 
> 

> Absolutely not. 

OK with me for the power planes. 

What about using the 2 INT layers to make special power planes for 
the SDRAM' s? 

I think the main issue is keeping the SDRAMS and Euterpe on the same plane. 

But before going further, I think we need to re- visit the amount 

of noise the SDRAM will inject into the power delivered to Euterpe and Calliope 

using the L- shape power plane layout, I unfortunately don't have all 

the data for that. 

Could you give me a rough estimate of the supply current characteristic 

for the SDRAM being accessed. 

I cannot find waveforms in any of the databooks. But from experience I would say you 
should expect a spike of 50 - 100mA of a few ns duration during RAS precharge. I would be 
more worried about the I/O drivers which are switching full 3V rail to rail with approx 
Ins edge rate into order 20pF We can have about 50 of these switching simultaneously. 

For Euterpe smd Calliope, we have been using 2A current spikes at 1.2GHz, 
300ps wide. Is it OK? 

Bill would have to comment on the amplitude and duration. However, the current target 
cycle time on Euterpe s 1.08GHz (ie lOx the 54MHz reference), so it's contribution will 
not have the same spectrum as Calliope. 
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> Following advices from our EMI/PCC consultant, do we have enough 

> reservoir capacitances around the SDRAM 's to guarantee an 

acceptable 

> ripple. 
> 

> What is the acceptable ripple? 
> 

I will re-calculate the acceptable ripple for analog Calliope. I takes 
into account the noise frequency (lOOMHZ + odd harmonics from SDRAM) , the 
amount of decoupling on the digital and the analog side and the series 
impedance of the L- shape power plane, 

SDRAM is likely to be running soraewhat lower than lOOMHz because the vendors have not yet 
been able to make parts above 83MHz. 

We take the SOFA frequency 1080 and divide by an integer to get a frequency lower than but 
as close as possible to the maximum DRAM rate. 

Tim 
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Subject: 


From: 


Sent: 

To: 

Cc: 


ong (Warren R. Ong) 

Friday, November 11, 1994 8:03 PM 

Tom Laidig' 

•tbr (Tim B. Robinson)'; 'geert (Geert Rosseel)'; 'hopper (Mark Hofmann)'; 'age (Alan Corry)' 
Re: resistor code cliange from 5 to 6 


>FroTn Tom Laidig . . . 

@ 

@ Bruce Bateman writes: 

@ I 

® 1 1 now understand that it has been decided to change the resistor ® | code on euterpe 
from a value of 5 to 6. Although I haven't seen 


® 

@ I don't think there's any plan to change the resistor code for the ® caches or any other 
custom block. The problem is that the logic doesn't @ fit in the sofa, and bumping the 
power level up should help reduce gate @ size. 

@ 

Thanks, Tom. Now I understand the reason for the resistor code change. 

Tim Sl Geert, should all of the exlax arrays in Euterpe be redesigned? Some area savings 
might be found in the din & dout FF of the array, but no savings will be found in the 
memory cells and word drivers. 


(snip) 


Warren . 
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From: ong (Warren R. Ong) 

Sent: Friday, November 11, 1994 8:08 PM 

To: 'Geert Rosseel' 

Subject: Re: IMMINENT DECISION : Euterpe SOFA Power 


>Frora Geert Rosseel . , . 

@ 
® 

@ Hi, 

@ 

@ 

@ In order to make the euterpe logic fit on the 10x10 die, 
@ we have to increase the power of the SOFA area with 20%. 

® This will give all our gates a higher drive capability and therefore ® we can use 
smaller gates for the same drive. 

@ 

@ We are currently rebuilding the library and after that, 

@ we'll run a set of experiments. If the results are good, this ® will become a FINAL 

decision. We'll know the results in ® about a week. 

@ 

& 

® Geert 

@ 

@ 

Are the knob domains constructed so that ALL custom blocks have separate knob control from 
all sofa blocks? If not, we should re-simulate the custom blocks that must share knob 
domains with lock blocks. 

Warren . 
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To: 


Subject: 


Cc: 


Sent: 


From: 


tbr 

Friday, November 11, 1994 10:49 PM 

'Bruce Bateman' 

'euterpe@kephalos' 

resistor code change from 5 to 6 


Follow Up Flag: Follow up 
Flag Status: Red 

Brace Bateman wrote (on Fri Nov 1 1): 

I now understand that it has been decided to change the resistor 
code on euterpe from a value of 5 to 6. Although I haven't seen 
any discussion of this decision, I assume it is to help meet the 
speed targets. However, I should point out that the custom blocks, 
and particularly the cache were designed at resistor code = 5 and 
were not simulated at higher values. While I don't have particular 
concerns regarding functionality, I should point out that at least 
in the cache, power bus wiring was extremely tight and that the 
currents used for sizing the busses for IR drops and more importantly 
for electro-migration were based upon a resistor code of 5, 
Increasing the code to 6 will likely cause some power busses to 
exceed their EM limits by the percentage power increase (20%?). 

We are investigating this change as a way to reduce the atom count 
while maintaining the cycle time. There is no reason to change the 
knob setting for the custom structures. By adjusting the knobs for 
the SOFA we get the same speed from smaller cells and so can increase 


density. 


Tim 
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From: Tim B. Robinson [tbr@kephalos] 

Sent: Friday, November 11 , 1 994 1 0:49 PM 

To: 'Bruce Bateman' 

Cc: 'euterpe@kephalos' 

Subject: resistor code change from 5 to 6 


Bruce Bateman wrote (on Fri Nov 11) : 

I now understand that it has been decided to change the resistor 
code on euterpe from a value of 5 to 6. Although I haven't seen 
any discussion of this decision, I assume it is to help meet the 
speed targets. However, I should point out that the custom blocks, 
and particularly the cache were designed at resistor code = 5 and 
were not simulated at higher values. While I don't have particular 
concerns regarding fimctionality , I should point out that at least 
in the cache, power bus wiring was extremely tight and that the 
currents used for sizing the busses for IR drops and more importantly 
for electro-migration were based upon a resistor code of 5 . 
Increasing the code to 6 will likely cause some power busses to 
exceed their EM limits by the percentage power increase (20%?) . 

We are investigating this change as a way to reduce the atom count while maintaining the 
cycle time. There is no reason to change the knob setting for the custom structures. By 
adjusting the knobs for the SOFA we get the same speed from smaller cells and so can 
increase density. 

Tim 
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From: tbr 

Sent: Friday. November 1 1 , 1 994 1 0:56 PM 

To: 'Jean-Yves Michel' 

Cc: 'bill@thalia"; 'graham@thalia'; 'hestia@thalia'; 'noel@thalja'; 'phnip@thalia'; 'tom@thalia' 

Subject: hestia power planes 


Follow Up Flag: Follow up 
Flag Status: Red 


Jean- Yves Michel wrote (on Fri Nov 11); 

Here is the latest proposal, pending a final OK from Tom and Philip 
on the pcb stack-up: 

we will have 2 seperate power/gnd planes, one for Euterpe and the SDRAM 
and one for Calliope and peripherals. The calliope planes will be L-sh^3ed 
and the other one will be closer to a rectangle. 


calliope planes 

. CALLIOPE . — euterpe/SDRAM planes 


I 


EUTERPE |. 

DC/DC j. 

I. 

SDRAM |. 

3.3V GND|. 
X X |. 

I. 


There will be a small supply voltage difference between euterpe and 
calliope due to IR drop but the differential inter&ce should not be affected. 

In order to have these 4 planes, we will have the following PCB stack-up: 

component .5oz 

26mils dielectric 
power 1 2oz 

2mils dielectric 
ground 1 2oz 

6mils dielectric 
ground 2 2oz 

2mils dielectric 
power 2 2ox 

26mils dielectric 
solder .5oz 
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outside the outlined area, the 4 internal layer will be used differently 

to carry power (3.3, 5 and 12V), current carrying ground planes, shields and 

chassis ground planes. 

If you have any objection, raise your voice immediately. A lot of layout 
will be done this week-end, so the power plane scheme should be 
finalized by the end of the day. 

Looks good to me. 
Tim 
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From: 
Sent: 
To: 
Cc: 

Subject: 


Tim B. Robinson [tbr@tlialia] 
Friday, November 11, 1994 10:56 PM 
'Jean-Yves Micliel' 

'bl)l@thalia'; 'graham@thalia'; 'hestia@thalia'; 'noel@thalia'; 'phjlip@thalia'; 'tom@thalla' 
hestia power planes 


Jean- Yves Michel wrote (on Fri Nov 11) : 

Here is the latest proposal, pending a final OK from Tom and Philip 
on the pcb stack-up : 

we will have 2 seperate power/gnd planes, one for Euterpe and the SDRAM 
and one for Calliope and peripherals. The calliope planes will be L-shaped 
eind the other one will be closer to a rectangle. 


calliope planes 
euterpe/ SDRAM planes 


DC/DC 


3.3V 
X 


GND 
X 


There will be a small supply voltage difference between euterpe and 

calliope due to IR drop but the differential interface should not be affected. 

In order to have these 4 planes, we will have the following PCB 
stack -up: 


component 
power 1 
ground 1 
ground 2 
power 2 
solder 


26mils dielectric 
2mils dielectric 
emils dielectric 
2mils dielectric 
26mils dielectric 


. Soz 

- 2oz 

- 2oz 

- 2oz 

- 2ox 

■ .5oz 


outside the outlined area, the 4 internal layer will be used differently 

to carry power (3.3, 5 sind 12V), current carrying ground planes, shields and 

chassis groimd planes. 

If you have any objection, raise your voice iinniediately . A lot of layout 
will be done this week-end, so the power plane scheme should be 
finalized by the end of the day. 

Looks good to me . 
Tim 
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Subject: 


From: 


Sent: 

To: 

Cc: 


tbr (Tim B. Robinson) 

Friday, November 11, 1994 11:14 PM 

'phi!ip@microunity.com' 

'Geert Rosseel'; 'harclheads@ambiorix'; 'hestia@ambiorix' 
Re: IMMINENT DECISION : Euterpe SOFA Power 


philip@MicroUnity.com wrote (on Fri Nov 11) : 

What does this mean to the total power consumption (and therefore 
dissipation) of the euterpe chip? If most of the chip is SOFA, does this 
mean a 20% increase in overall chip power consumption? 

It will mean approximately 20% increase in the SOFA component only. 

Prior to this change we had about 46W in the SOFA so it will add about 9W. There may be 
second order effects in our favor resulting from the shorter wires as the average gate 
size decreases, but that effect is likely to be < IW. 


Tim 
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Subject: 


From: 


Sent: 

To: 

Cc: 


tbr (Tim B. Robinson) 

Friday, November 11, 1994 11:53 PM 

'ong (Warren R. Ong)' 

'age (Alan Corry)'; 'geert (Geert Rosseel)'; 'hopper (Mark Hofmann)'; Tom Laidig' 
Re: resistor code change from 5 to 6 


Warren R. Ong wrote (on Fri Nov 11) : 


>From Tom Laidig . . . 
® 

@ Bruce Bateman writes: 


@ I 

@ 1 1 now understand that it has been decided to change the resistor 
@ I code on euterpe from a value of 5 to 6 . Although I haven't seen 


(snip) 


@ 

@ I don't think there's any plan to change the resistor code for the 

@ caches or any other custom block. The problem is that the logic doesn't 

® fit in the sofa, and bumping the power level up should help reduce gate 

® size. 

@ 

Thanks, Tom. Now I understand the reason for the resistor code 
change . 

Tim & Geert, should all of the exlax arrays in Euterpe be 
redesigned? Some area savings might be found in the din & dout FF 
of the array, but no savings will be found in the memory cells and 
word drivers. 

I don't think we should redesign them. The saving would be too small to justify it. 


Tim 
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From: Kurt Wampler [wampler@hestia] 

Sent: Friday, November 11 , 1 994 11 :58 PM 

To: 'vanthof@hestla'; Vo@hestia' 

Cc: 'geert@hestia'; 'hopper@hestia'; 'lisar@hestia'; 'tbr@hestia'; Vo@hestia' 

Subject: Re: euterpe Ivs finished 


>vant wrote .... 

>> 

>> 

>>Hi Tom, 

» The euterpe Ivs finished. The resulst are in 
>> 

>> /u/vanthof/compass/mobi/euterpe/tapeout /euterpe, compare 
> > 

>>There are about 300 devices unmatched. A quick glance through the 

>>f ile shows some problems 

>>VRR34_0 -> VRR35_0, 

>>VRR54_0 -> VRR55_0, 

> 

Vo replied: 


>Kurt confirmed that the domain shorts were caused by a faulty clockbias 
SW . 

>He has implemented a fix and released them . 

These clockbias bugs seem to have a loooong gestation period. This one 
took many hours to track down and understand. The seed of this problem 
was planted last December 17, when a couple of lines of code were 
inserted to add an instance of IFL_DRV at every mast/spar junction. 
The lines were inserted one line too high in the source code, but this 
alone caused no malfunction. Many revisions of the clockbias 
software were made since then. The current problem was introduced in 
August, when an enhancement was reqiaested to allow the gaff wiring row to 
be positioned either above or below the mast. Many small code 
modifications were required to support this change. One additional line 
was inserted above the out -of -sequence line lurking in the source code. 
This caused the out -of -sequence line to emit a whole wall of IFL_DRV 
straps along any spar driving atoms to its left in its last row. This 
was not caught in the LVS of cgclockbias, however, since those IFL_DRV 
straps just dangle and don't hook to anything vintil cgclockbias is 
instantiated in the main SOFA. The short then finally became apparent in 
the top-level LVS. It's unfortunate that we didn't catch it earlier, but 
I can't think of a way we could have, short of LVS'ing cgclockbias in the 
context of the whole baseplate. 

>An update to fix this problem in the snapshot should not invalidate the 
>lower baseplate layers but since it will probably take just as long 
> (compared to ref racturing) to verify that this is really the case , 
>what do you say we just redo the whole thing so we get this change 
>along with other proteus changes ? 

We can either XOR the existing pattern files after the snapshot area has 
been updated, or we can just refracture. It's about the same amount of 
CPU time to do either one; I would probably opt to refracture, since if 
the XOR found anything wrong, we would just have to refracture again 
to correct the problem. (The IFL_DRV cell doesn't contain any geometry 
on the baseplate layers, so this change *should* only affect the metal 
layers.) If we want to update other cells in proteus which would change 
some of the baseplate layers, it's only a couple days' runtime to redo 
the 15 layers we've fractured so far. (Having only one primary chip 
to fracture instead of three helps quite a bit.) 

- Kurt 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Tim B. Robinson [tbr@hestial 
Saturday, Novennber 12, 1994 12:04 AM 
Tom Vo' 

'geert@hestia'; •hopper@hestia'; 'lisar@hestia'; 'vanthoflghestia'; Vanf; Voighestia'; 'Kurt 
Wampler* 

Re: euterpe Ivs finished 


Tom Vo wrote (on Fri Nov 11) : 


vant wrote 


> 


> 


>Hi Tom, 

> The euterpe Ivs finished. The resulst are in 


> /u/vanthof/compass/mobi/euterpe/tapeout /euterpe . compare 


> 


>There are about 3 00 devices unmatched. A quick glance through the file 
>shows some problems 
>VRR34_0 -> VRR35_0, 
>VRR54_0 -> VRR55_0, 

Kurt confirmed that the domain shorts were caused by a faulty clockbias SW . 
He has implemented a fix and released them . 

An update to fix this problem in the snapshot should not invalidate 
the lower baseplate layers but since it will probably take just as long 

(compared to ref racturing) to verify that this is really the case , what do you 
say we just redo the whole thing so we get this change along with other proteus 
changes ? 

We have still not managed to get a full remake in the snapshot proteus. The timing is 
rimning now, but I think we need to pick up the very latest top level BOM (5.570) to see 
kurt's change. 

We would also need to get a new BOM in the eutepre/verilog/bsrc area to pick up 
the changes in the pads area . 


tvo 
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Subject: 


From: 


Sent: 

To: 

Cc: 


Tim B. Robinson [tbr@liestia] 
Saturday, November 12, 1994 12:12 AW! 
'Kurt Wampler' 

'geert@tiestia'; 'hopper@hestia'; 'lisar@liestia'; 'vantliof@liestia'; 'vo@iiestia' 
Re: euterpe Ivs finished 


Kurt Wampler wrote (on Fri Nov 11 > : 

We can either XOR the existing pattern files after the snapshot area has 
been updated, or we can just refracture. It's about the same amount of 
CPU time to do either one,- I would probably opt to refracture, since if 
the XOR found anything wrong, we would just have to refracture again 
to correct the problem. (The IFL_DRV cell doesn't contain any geometry 
on the baseplate layers, so this change * should* only affect the metal 
layers . ) If we want to update other cells in proteus which would change 
some of the baseplate layers, it's only a couple days' runtime to redo 
the 15 layers we've fractured so far. (Having only one primary chip 
to fracture instead of three helps quite a bit . ) 

There have been many updates to the proteus snapshot, none of which should have affected 
baseplate layers. I would suggest we definitely re-run and confirm that that is indeed 

the case after we manage to get a clean run of the top level proteus make. In the mean 
time, if it makes sense just to re LVS to make sure the problem really is fixed, we need 
to get BOM 5.57 0 into the snapshot. I think we can do that without clobbering the make 
which is currently running. 


Tim 
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From: 
Sent: 
To: 

Subject: 


hopper (Mark Hofmann) 

Saturday, November 12, 1994 11:16 AM 

'Geert Rosseel' 

Re: pim2pif, pifpack ? 


Geert Rosseel writes: 

In /n/ghidra/s3/geert/euterpe/verilog/bsrc/gards 

I use pim2pif & pifpack using the Makefiles in verilog/bsrc (Makef ile. tst) , 
in I get a good geert_euterpe- iter. pirn. pif . 0 but the 
geert_euterpe-iter .pim.pif . 0 .packed seems t have lost a lot of data. 


Hmm . . , 

I guess the .packed output is long gone by now. Are you still having the problem? I 
noticed many non-sofa cells in the .pif file. These should just be passed through 
untouched by pifpack and appear in the output (I thought maybe you were losing those] . I 
don't see anything funny in the current .pif file in theat directory. 


HI Geert, 


-mark 
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From: tbr 

Sent: Saturday, November 1 2, 1 994 11 :26 AM 

To: 'briani (Brian Lee)' 

Cc: 'hopper (Mark Hofmann)' 

Subject: Re: phobos 

Follow Up Flag: Follow up 

Flag Status: Red 


Brian Lee wrote (on Sat Nov 12): 
Tim B. Robinson writes: 


[Ft up but idle. I see it int he list of spice machines. Should deal 
I be using it? 

I 

jTim 

I 

Hmmmm. Which list? I don't see it on the snapshot list; 

cat /n/auspex/s23/euterpe-proteus-cp/spice/m isc/spice_machines 

ares 13 1.50 

frodo 13 1.50 

kephalos 13 1.50 

mercury 13 1.50 

merope 13 1.50 

narcissus 13 1.50 

pegasus 13 1.50 

psyche 13 1.50 

thalia 13 1.50 

ambiorix 10 1.50 

hera 10 1.50 

pelorus 10 1.50 

polyhymnia 10 1.50 

In the list of tools hopper constructed: 

hspice meta-software rhea ambiorix ares boa frodo hera kephalos 
mercury merope narcissus pegasus 
pelorus phobos polyhymnia psyche thalia 

Tim 
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From: arya (Arya Behzad) 

Sent: Saturday, November 12, 1994 4:39 PM 

To: 'woody@thalia'; 'tbr@thalia'; 'ras@thalia'; 'yves@thalia'; 'dane@thalia'; 'noel@thalia'; 

'bi]l@thalia'; 'rich@thalia'; 'tbe@thalia'; 'graham @thalia' 
Cc: 'hestia@thaiia' 
Subject: Re: Layout review 


Done. Setails below. 


> From graham@thalia Thu Nov 10 17:52:09 1994 

> From: grahamOthalia (Graham Y. Mostyn) 

> To: woody®thalia, tbr@thalia, ras®thalia, yves@thalia, dane®thalia, 

> arya@thalia, noel@thalia, bill®thalia, richothalia, tbe®thalia 

> Subject: Layout review 

> Cc; hestia@thalia, graham®thalia 

> Content -Length: 870 

> X- Lines: 30 
> 

> Now that the main board layout is close to completion, we would like 

> all of the circuit designers to check the final captured schematics 

> and this interim layout, in particular tracing out the sections that 

> they own. 
> 

> We're therefore circulating tomorrow (Friday) schematics and plots to 

> the following people, and would appreciate it if you could report to 

> Arya at or before the 3PM Monday netlist meeting of discrepancies in 

> any of the three databases: 

> SECTION DESIGNER 


DONE 

DONE 
> 

DONE 
> 

DONE 


DRAM, Euterpe, smart card woody, tbr 

Upstream transmitter ras 
Ch3/4 transmitter ras 

QPSK RX ras 


> Audio yves 

> Phone yves 

Jean Yves has done this directly with Patty. 

> Video dane 

Done. Dane will have to review when he comes back on Tuesday. 

> RF receivers arya 
In progress with Pattie 

> Power planes noel, bill, graham 
in progress 

> Power supplies noel 

It looks like we won't have power supply on this board. Am I right? 

> IR noel 
Noel did this directly with Pattie. 

> VCOs, SAW osc. rich 
Done . 

> Mechanical compatibility tbe 

Tom, please use the drawings that Pattie provided. If you need more info, pleaselet me 
know. 

> Thanks for your help - the netlist meeting is held in the boxers* 

> conference room. 
> 

> Graham. 
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Thanks . 
-Arya 
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Subject: 


Sent: 

To: 

Cc: 


From: 


brianl (Brian Lee) 

Saturday, November 12, 1994 4:41 PM 
Tim B. Robinson' 

'geert (Geert Rosseel)'; 'brianl (Brian Lee)' 
Re: ieafgen 


Tim B. Robinson writes: 

How easy is it to change the code generated for the xlib entries? 

I am trying to convert euterpe to run on the IKOS accelerator. Up to 
now we have been modeling all the flops as negative edge triggered off 
phi_A2P. IKOS does not have a negative edge triggered primitive flop. 
One way to deal with this would be to replace dffnq globally by dffq 
and change phi_A2P to phi_B2P in each dffq instance. This would then 
be a positive edge triggered flop off the opposite clock edge. 
I can then map that directly to either ikos or zycad primitives. 

If I understand you correctly, then for example, in xbffbdf2s.v 

// VERSION Version of Sun Sep 11 11:31:14 PDT 1994 NOISREV macromodule xbffbdf2s ( 
PHI_A2P1C, PHI_B2P1C, PHI_A2P2C, PHI_B2P2C, PHI_A2P3C, PHI_B2P3C, DO_ADMPH, DO_ANDMPH, 
Q_ADOPF, Q_ANDOPF) ; 

input PHI_A2P1C, PHI_B2P1C; 
input PHI_A2P2C, PHI_B2P2C; 
input PHI_A2P3C, PHI_B2P3C; 
input DO_ADMPH; 
input DO_ANDMPH; 
output Q_ADOPF, Q_ANDOPF; 
supplyl one; 

dffnq #1 (Q_ADOPF, one, DO_ADMPH, one, PHI_A2P1C) ; 
not (Q_ANDOPF, Q_ADOPF) ; 

endmodule 

the only line that would change is 

dffnq #1 (Q_ADOPF, one, DO_ADMPH, one, PHI_A2P1C) ; 


dffq #1 (Q_ADOPF, one, DO_ADMPH, one, PHI_B2P1C) ; 

If this is true, then I think the change is easy. The change would only affect xlib/*.v 
files and those derived from them (dxlib, zxlib, exlib) . 

Is this the desired scope or are there other representations that would need to be changed 
also? 


to 


Brian L. 
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From: tbr 

Sent: Saturday. November 12, 1994 4:46 PM 

To: 'arya (Arya Behzad)' 

Cc: 'bill@thalia'; 'pmayer'; 'dane@thalia'; 'graham@thalia'; 'hestia@thalia'; 'noel@tha!ia'; 

'ras@thalia'; 'rich@thalia'; 'tbe@thalia'; 'wcx)dy@tha)ia'; 'yves@thalia' 

Subject: Re: Layout review 

Follow Up Flag: Follow up 

Flag Status: Red 


Aiya Behzad wrote (on Sat Nov 12): 
Done. Setails below. 


> From graham@thalia Thu Nov 10 17:52:09 1994 

> From; graham@thalia (Graham Y. Mostyn) 

> To: woody@thalia, tbr@thalia, ras@tha!ia, yves@thalia, dane@thalia, 

> arya@thalia, noel@thalia, bill@thalia, rich@thalia, tbe@thalia 

> Subject: Layout review 

> Cc: hestia@tha1ia, graham@thalia 

> Content-Length: 870 

> X-Lines: 30 
> 

> Now that the main board layout is close to completion, we would like 

> all of the circuit designers to check the fmal captured schematics 

> and this interim layout, in particular tracing out tiie sections that 

> they own. 
> 

> We're therefore circulating tomorrow (Friday) schematics and plots to 

> the following people, and would appreciate it if you could report 

> to Arya at or before the 3PM Monday netlist meeting of discrepancies in 

> any of the three databases: 

> SECTION DESIGNER 
> 

> DRAM, Euterpe, smart card woody, tbr 
DONE 

> Upstream transmitter ras 
DONE 

> Ch3/4 transmitter ras 
DONE 

> QPSK RX ras 
DONE 

> Audio yves 

> Phone yves 

Jean Yves has done this directly with Patty. 

> Video dane 

Done. Dane will have to review when he comes back on Tuesday. 

> RF receivers arya 
In progress with Pattie 

> Power planes noel, bill, graham 
in progress 

> Power supplies noel 
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It looks like we won't have power supply on this board. Am I right? 

We do want it there. We have said that we will probably leave 
the DC/DC converter off and use a lab supply to bring up prototypes, 
but we need to be able to put the power supply on some boards in order 
to be able to measure the noise it generates in the real board/box 
environment. Otherwise we will not be able to measure the 
effectiveness of the decoupling, planes and shielding at containing 
the noise. 

> IR noel 
Noel did this directly with Pattie, 

> VCOs, SAW osc. rich 
Done. 

> Mechanical compatibility tbe 

Tom, please use the drawings that Pattie provided. If you need more info, 
pleaselet me know. 


> Thanks for your help - the netlist meeting is held in the boxers* 

> conference room. 
> 

> Graham. 

> 
> 

Thanks. 
-Arya 
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From: tbr (Tim B. Robinson) 

Sent: Saturday, November 12, 1 994 4:46 PM 

To: 'arya (Arya Behzad)' 

Cc: 'bi(l@thalia'; 'pmayer'; 'dane@thalja'; 'graham@thalia'; 'hestia@thalia'; 'noel@thatia'; 

'ras@thalia'; 'rich@thalia'; 'tbe@thalia'; ^Aff^ody@thalia'; 'yves@thalia' 
Subject: Re: Layout review 


Arya Behzad wrote (on Sat Nov 12) ; 
Done. Setalls below. 


> From grahamOthalia Thu Nov 10 17:52:09 1994 

> From: grahamOthalia (Graham Y. Mostyn) 

> To: woody®thalia, tbrOthalia, ras®thalia, yvesOthalia, daneOthalia, 

> arya@thalia, noel@thalia, bill®thalia, rich@thalia, 
tbe@thalia 

> Subject: Layout review 

> Cc: hestia®thalia, grahara@thalia 

> Content -Length: 870 

> X- Lines: 30 
> 

> Now that the main board layout is close to completion, we would like 

> all of the circuit designers to check the final captured schematics 

> and this interim layout, in particular tracing out the sections that 

> they own. 

> 

> We're therefore circulating tomorrow (Friday) schematics and plots to 

> the following people, and would appreciate it if you could report 

> to Arya at or before the 3PM Monday net list meeting of discrepancies in 

> any of the three databases: 

> SECTION DESIGNER 
> 

> DRAM, Euterpe, smart card woody, tbr 
Upstream transmitter ras 
Ch3/4 transmitter ras 
QPSK RX ras 


DONE 
> 

DONE 
> 

DONE 
> 

DONE 


> Audio yves 

> Phone yves 
Jean Yves has done this directly with Patty. 

> Video dane 

Done. Dane will have to review when he comes back on Tuesday. 

> RF receivers arya 
In progress with Pattie 

> Power planes noel, bill, graham 

in progress 

> Power supplies noel 

It looks like we won't have power supply on this board. Am I right? 

We do want it there. We have said that we will probably leave the DC/DC converter off and 
use a lab supply to bring up prototypes, but we need to be able to put the power supply on 
some boards in order to be able to measure the noise it generates in the real board/box 
environment . Otherwise we will not be able to measure the effectiveness of the 
decoupling, planes and shielding at containing the noise. 

> IR noel 
Noel did this directly with Pattie. 

> VCOs, SAW osc. rich 
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Done . 

> Mechanical compatibility tbe 

Tom, please use the drawings that Pattie provided. If you need more info, 
pleaselet me know. 

> 

> Thanks for your help - the netlist meeting is held in the boxers' 

> conference room. 
> 

> Graham. 


Thanks . 
-Arya 
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From: 
Sent: 
To: 

Subject: 


geert (Geert Rosseel) 

Saturday, November 12, 1994 5:08 PM 

'geert' 

call chappell 


vant wrote 


> 


> 


>Hi Tom, 


> 


The euterpe Ivs finished. The resulst are in 


> 


> 


/u/vanthof /compass/mobi/euterpe/tapeout/euterpe . compare 


> 


>There are about 300 devices unmatched. A quick glance through the file 
> shows some problems 
>VRR34_0 -> VRR35_0, 
>VRR54_0 -> VRR55_0, 

Kurt confirmed that the domain shorts were caused by a faulty clockbias SW . 
He has implemented a fix and released them . 

An update to fix this problem in the snapshot should not invalidate the lower baseplate 
layers but since it will probably take just as long (compared to ref racturing) to verify 
that this is really the case , what do you say we just redo the whole thing so we get this 
change along with other proteus changes ? 

We would also need to get a new BOM in the eutepre/verilog/bsrc area to pick up the 
changes in the pads area . 


tvo 
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From: 


tbr 


Sent: 


Saturday. November 12. 1994 5:49 PM 


To: 


'doi' 


Subject: 


vltree 


Follow Up Flag: Follow up 
Flag Status: Red 


tbr@aphrodite ~/euterpe/ikos 615 % !vl 

vltree -D -y --/proteus/veri log/ml ib -y ~/proteus/verilog/xlib test2.v 
Extracting names from library /n/auspex/sl5/tbr/proteus/verilog/mIib 
Extracting names from library /n/auspex/slS/tbr/proteus/verilog/xlib 
Processing file test2,v 
Adding Local Cells: test2.v 
Adding or5_l Directory test2.v 
Adding ot2_1 Directory test2.v 
test2.v 

/n/auspex/s 1 5/tbr/proteus/verilog/mIib/or2_l .v 
/n/auspex/s 15/tbr/proteus/verilog/mlib/or5_l .v 


The two mlib cells should each be calling out one celt from 
xlib. 
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From: torn (Tom Laidig) 

Sent: Saturday, November 12, 1994 9:08 PM 

To: 'Lisa Robinson' 

Cc: 'sysadm'; 'doi (Derek Iverson)'; 'torn (Thomas Laidig)' 
Subject: Re: forwarded message from Mail Delivery Subsystem 

Lisa Robinson writes: 
I 

I Start of forwarded message 

[Status: RO 

|X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] 

I ["977" "Sat" "12" "November" "1994" "16:55:17" "GMT" "Mail Delivery Subsystem" "Mailer-Daemon " nil "31" 
"Returned mail: Deferred: Name server: host name lookup failure" "'^From:" nil nil "11"]) 
]Retum-Path: <Mailer-Daemon> 

IReceived: from clio.microunity.com by gaea.microunity.com (4.1/musel.3) 

I id AA12491; Sat, 12 Nov 94 08:43:15 PST 

IReceived: from localhost by clio.microunity.com (8.6.4/muse-sw.2) 

I id QAA00205; Sat, 12 Nov 1994 16:55:17 GMT 
IMessage-Id: <19941 1 121655.QAA00205@clio.microunity.com> 
]From: Mailer-Daemon (Mail Delivery Subsystem) 
|Apparently-To: <lisar> 

jSubject: Returned mail: Deferred: Name server: host name lookup failure 

jOate: Sat, 12 Nov 1994 16:55:17 GMT 

I 

|The original message was received at Sat, 12 Nov 1994 16:55:08 GMT 
jfrom nosferatu.microunity.com [192.216.195.36] 

! 

I Transcript of session follows 

|554 mailer mail died with signal 13 
■Arguments: mail -r lisar -d torn 

|<tom>... Deferred: Name server: host name lookup failure 

f 

I Original message follows 

IRetum-Path: <lisar> 

IReceived: from nosferatu.microunhy.com by clio.microunity.com (8,6.4/muse-sw.2) 

I id QAA00204; Sat, 12 Nov 1994 16:55:08 GMT 

IReceived: from localhost by nosferatu.microunity.com (8.6.4/muse-sw.2) 

i id IAA01254; Sat, 12 Nov 1994 08:54:45 -0800 

IDate: Sat, 12 Nov 1994 08:54:45 -0800 

jFrom: lisar (Lisa Robinson) 

IMessage-Id: <199411 12I654.IAA01254@nosferatu.microunity.com> 
|To: euterpe-checkins-dist, lisar, tbr, torn 
[Subject: euterpe/verilog/bsrc Makefile 
I 

lUpdate of /p/cvsroot/euterpe/verilog/bsrc 

jln dkectory nosferatu:/N/aphrodite/root/s3/euterpe/verilog/bsrc 

I 

jModified Files: 
I Makefile 
|Log Message: 


|Put back geert's changes. 

I 

I 
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I — __. End of forwarded message 

I 

Hmmm... 16:55 GMT is 8:55 PST. Clio rebooted this morning, and came up 
at 9:03 PST. I note that all the other weitek machines except psyche 
rebooted this morning as well: 

-> mioad weitek 

phobos up 11:28, 0 users, load 0.00, 0.00, 0.00 
thoas up 9:24, 0 users, load 0.00, 0.00, 0.00 
aphrodite up 11:27, 0 users, load 0.00, 0.00, 0.00 
marathon up 9:49, 0 users, load 0.00, 0.00, 0.00 
rimulac up 10:05, 0 users, load 0.02, 0.00, 0.00 
hestia up 11:39, 1 user, load 0.04, 0.00, 0.00 
millennium up 9:43, 0 users, load 0.05, 0.14, 0.00 
mercury up 8:39, 0 users, load 0.06, 0.00, 0.00 
Clio up 10:00, 6 users, load 0.30, 0.26, 0.00 
psyche up 50+02:48, 0 users, load 1.20, 1,05, 0.76 
pegasus up 9:53, 0 users, load 1.30, 1.28, 1.28 
frodo up 9:38, 0 users, load 1.32, 1.28, 1.28 
thalia up 9:50, 0 users, load 1.35, 1.10, 1.14 
merope up 9:29, 0 users, load 1.36, 1.28, 1.28 
narcissus up 9:50, 0 users, load 1.37, 1.19, 1.17 
ares up 11:30, 0 users, load 1.79, 1.51, 0.96 
polyhymnia up 9:29, 0 users, load 1.84, 1.64, 1.31 
-> date 

Sat Nov 12 19:07:03 PST 1994 
-> 

Do we know why this happened? 


ooooO Ooooo 

(JO 
]( Tom )| 
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Sent: 


From; 


tbr 

Saturday, November 12. 1994 11:38 PM 


Subject: 


To: 


Cc: 


'doi' 

'woody' 

vltree 


Follow Up Flag: Follow up 
Flag Status: Red 

It cannot handle euterpe/verilog/bsrc/at/at.v. The problem 
seems to be: 

orfn6_l/*nand*/ Upa4732Eq8000Rl 1 ( phi_A2P, phi_B2P ,paR10_N[47] ,paR10[46] ,paR10[45] ,paR10[443 
,paR10[43] .paR10[42] ,paR10[41] ,paR10[40] ,paR10[39] ,paR10[38] 

.paR10[37] .paR10[36] .paR10[35] ,paR10[34] ,paR10[33I ,paR10[32] .pa4732Eq8000Rl 1_N, pa4732Eq8000Rl 1 ); 

where it takes the module name to be 

orfn6_l/*nand*/ 

There are other cases such as 

dorff2_l /*NandN*/ Ufi«EnblR10 ( phi_A2P, phi_B2P ,gvaR8R9[47], gvaR8R9_N[47] ,ndxFrcR9_N[l], ndxFrcR9 
[1] ,frcEnblR10_N, fix;EnbIR10 ); 

where it takes the module name to be /'NandN*/ 

Looks like stripping comments would be a good move 


Tim 
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From: 


tbr 


Sent: 


Sunday, November 13, 1994 12:09 AM 

•dor 

vltree 


To: 


Subject: 


Follow Up Flag: Follow up 
Flag Status: Red 

There is another problem. It's failing to find some modules. 

I have been running it over the whole of euterpe. You can see how by 

looking at the end ot ~tbr/eutape/verilog/bsrc/Makefile. 

It's clearly getting confused by comments, but I have been stripping 
Ifaem by changing the cpp commmd which is used to go from .V to .v 


Here's the sort of output I'm getting; 

ERROR; Cell iosync is not found in any library. 
ERROR: Cell orff3_l/*nand*/ is not found in any library. 
ERROR: Cell */ is not found in any library. 
ERROR: Cell nbal6x64 earow is not found in any library. 
ERROR: Cell nbal6x64_earowi is not found in any library. 
ERROR: Cell nbd32x64 earow is not found in any library. 
ERROR: Cell nbd32x64_earowi is not found in any library. 
ERROR: Cell priority is not found in any library. 
ERROR: Cell pqptr is not found in any library. 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Sunday, November 13, 1994 12:49 AM 

'brian! (Brian Lee)' 

'geert (Geert Rosseet)' 

Re: leafgen 


Brian Lee wrote (on Sat Nov 12) : 

Tim B. Robinson writes: 

How easy is it to change the code generated for the xlib entries? 

I am trying to convert euterpe to run on the IKOS accelerator. Up to 
now we have been modeling all the flops as negative edge triggered off 
phi_A2P. IKOS does not have a negative edge triggered primitive flop. 
One way to deal with this would be to replace dffnq globally by dffq 
and change phi_A2P to phi_B2P in each dffq instance. This would then 
be a positive edge triggered flop off the opposite clock edge. 
I can then map that directly to either ikos or zycad primitives. 

If I understand you correctly, then for example, in xbffbdf2s.v 

// VERSION Version of Sun Sep 11 11:31:14 PDT 1994 NOISREV 

macromodule xbffbdf2s ( PHI_A2P1C, PHI_B2P1C, PHI_A2P2C, PHI_B2P2C, PHI_A2P3C, 
PHI_B2P3C, DO_ADMPH, DO_ANDMPH, Q_ADOPF, Q_ANDOPF) ; 

input PHI_A2P1C, PHI_B2P1C; 
input PHI_A2P2C, PHI_B2P2C; 
input PHI_A2P3C, PHI_B2P3C; 
input DO_ADMPH; 
input DO_ANDMPH; 
output Q_ADOPP, Q_AJSIDOPF; 
supply 1 one; 

dffnq #1 (Q_ADOPF, one, DO_ADMPH, one, PHI__A2P1C) ; 
not ( Q_ANDO PP , Q_ADO PF > ; 

endmodule 

the only line that would change is 

dffnq #1 (Q_ADOPF, one, DO_ADMPH, one, PHI_A2P1C) ; 


dffq #1 (Q_ADOPF, one, do_admph, one, phi_B2P1C> ; 

If this is true, then I think the change is easy. The change would only 
affect xlib/*.v files and those derived from them (dxlib, zxlib, exlib) . 
Is this the desired scope or are there other representations that 
would need to be changed also? 

That's exactly the change and exactly the scope. I would want to try it out well before 
we unleashed anything on /u/chip though. 


to 


Tim 
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From: doi (Derek Iverson) 

Sent: Sunday, November 1 3, 1 994 3: 11 AM 

To: 'tbr (Tim B. Robinson)' 

Subject: vltree 

Tim B. Robinson writes: 

> 

> There is another problem. It's failing to find some modules. 

> I have been running it over the whole of euterpe. You can see how by 

> looking at the end ot ~tbr/euterpe/verilog/bsrc/Makefile. 
> 

> It's clearly getting confused by comments, but I have been stripping 

> them by changing the cpp command which is used to go from .V to .v 

> 
> 

> Here's the sort of output I'm getting: 

> 

> ERROR: Cell iosync is not found in any library. 

> ERROR: Cell orff3_l/*nand*/ is not found in any library. 

> ERROR: Cell */ is not found in any library. 

> ERROR: Cell nbal6x64 earow is not found in any library. 

> ERROR: Cell nbal6x64 earowi is not found in any library. 

> ERROR: Cell nbd32x64 earow is not found in any library. 

> ERROR: Cell nbd32x64_earowi is not found in any library. 

> ERROR: Cell priority is not found in any library. 

> ERROR: Cell pqptr is not found in any library. 


vltree currently makes the assumption that only module is defined per 

file. This way it doesn't have to open and parse every file in 

each possible directory but instead deduce their appropriate names 

by looking at the filenames. Should I open and parse all files 

or should we split out modules definitions into their own filename? 

I have put some rudimentary comment stripping code in, but until we 
start using Perl version 5 (which support 'minimal* pattern matching) 
this is done pretty stupidly. 

If we had an input line like 

foo /* deleted stuff */ bar /* more deleted stuff */ baz 
we would be left with 

foo baz 

when I was done. Comments split across lines won't be handled properly 
either. 

If we only have one C style comment per line this shouldn't be a problem. 

I don't know where the 'priority' name comes from, do you? 

Let me know what you thitik I should do about the first problem I wrote 
about above. 
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From: vanthof (vant) 

Sent: Monday, November 14, 1994 10:33 AM 

To: 'geert (Geert Rosseel)'; 'tbr (Tim B. Robinson)' 

Cc: 'vanthof (Dave Van't Hof)'; 'hopper (Mark Hofmann)' 

Subject: topt reporting mux select errors 


Morning, 

I was running some tests this morning on the tbreuterpe . edif in Tim's euterpe tree and 
found a total of 53 instances where the mux selects had no half swing drivers. I'm 
wondering how you would like this reported. 

I currently have topt report the instance name in the log file without changing the exit 
code status . 

What I could do is report the number of failures in the log file, but report the actual 
instance with all the drivers of it's select lines in the stat file. Would you like the 
exit code to be non-zero because of these failures? I imagine not, because it would stop 
all progress until these were fixed. 

Comments? 
Dave 

Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, 
Inc . 

"What rolls down stairs, alone or in pairs, rolls over the neighbor's dog? 

What's great for a snack and fits on your back? It's log, log, log!" 
LOG from BLAMMOl (tm) All kids love Logl #incluce 
<std disclaim. h> 
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From: tbr 

Sent: Sunday, November 13, 1994 11:27 AM 

To: 'doi (Derek Iverson)' 

Subject: vltree 
Follow Up Flag: Follow up 
Flag Status: Red 


Derek Iverson wrote (on Sun Nov 13): 

Tim B. Robinson writes: 

> 

> There is another problem. It's failing to find some modules. 

> I have been running it over the whole of euterpe. You can see how by 

> looking at the end ot ~tbr/euterpe/verilog/bsrc/Makefile. 
> 

> It's clearly getting conftised by comments, but I have been stripping 

> them by changing the cpp command which is used to go from .V to .v 
> 

> 

> Here's the sort of output I'm getting: 

> 

> ERROR: Cell iosync is not found in any library. 

> ERROR: Cell orff3_l/*nand*/ is not found in any library. 

> ERROR: Cell */ is not found in any library. 

> ERROR: Cell nbal6x64_earow is not found in any library. 

> ERROR: Cell nbal6x64_earowi is not found in any library. 

> ERROR: Cell nbd32x64_earow is not found in any libraiy. 

> ERROR: Cell nbd32x64_earowi is not found in any library. 

> ERROR: Cell priority is not found in any library. 

> ERROR: Cell pqptr is not found in any library. 


vltree currently makes the assumption that only module is defined per 
file. This way it doesn't have to open and parse every file in 
each possible directory but instead deduce their appropriate names 
by looking at the filenames. Should I open and parse all files 
or should we split out modules definitions into their own filename? 

Splitting out the modules would be a pain, especially as some of the 
files are automatically generated. 

I have put some rudimentary comment stripping code in, but imtil we 
start using Perl version 5 (which support 'minimal' pattern matching) 
this is done pretty stupidly. 

If we had an input line like 

foo /♦ deleted stuff */ bar /* more deleted stuff */ baz 
we would be left with 

foo baz 

when I was done. Comments split across lines won't be handled properly 
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either. 


I have changed the qpp command which we use when processing .V file to 
.V files to strip them. It won't take out all comments because there 
are lots of .v's that we get other ways and the comments are actually 
being put in by the tools so we can tell what went on However, as far 
as I know the only ones that are causing trouble are the ones put in 
manually. 

If we only have one C style comment per line this shouldn't be a problem. 

I don't know where the priority' name comes from, do you? 

No, and there are lots of others like 'unix.'! 

I will systematically remake all the .v's in this class and see how 

many of these go away. 

Let me know what you think 1 should do about the first problem I wrote 
about above. 

I think we would need to be able to handle that case and I'm surprised 
it has not come up before. There is a verilog parser already in perl 
that is used by the equation handling tools such as Veqn. Talk to 
hopper, there may be a short cut. 

Tim 
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From: ken (Ken Hsieh) 

Sent: Monday, November 14, 1 994 11 :69 AM 

To: 'hchu' 

Cc: 'tbr'; 'jt' 

Subject: Re: Sun OS 4.1.3 

Herman, 

It is floating license. 
Ken 


> From hchu Men Nov 14 09:28:42 1994 

> Date: Mon, 14 Nov 1994 09:28:34 -0800 

> From: hchu (Hennan Chu) 

> To: ken 

> Subject: Sun OS 4. 1.3 

> Content-Length: 143 1 
> 

>Ken, 

> 

> Can you look into v^hether the Icepak license is a node lock type or floating 
>type. Thank you. 

> 

> Herman 

> 
> 

> Begin Included Message 

> 

> >From tbr Fri Nov 1 1 21 :50:34 1994 

> Date: Fri, 1 1 Nov 1994 21:50:34 -0800 

> From: tbr (Tim B. Robinson) 

> To: hchu (Herman Chu) 

> Cc: hchu, jt, sysadm 

> Subject: Sun OS 4.1.3 

> Content-Length: 1058 
> 

> 

> Herman Chu wrote (on Fri Nov 1 1): 

> 

> Hi Tim, 

> 

> I have gotten a trial license for Icepak, a computational fluids dynamics (CFD) 

> software package, for my Sun Sparc 2 (phobos). The software requires Sun OS 

> 4. 1 .3 and phobos only has Sun OS 4. 1 . 1 . CFD software is very computational 

> intensive, a typical job runs minimum 4 hours and it can take as many as 

> several days to complete. I would need to have phobos' OS upgraded to 

> Version 4. 1 .3. The software trial is for 35 days from this past Wednesday. 
> 

> Thank you for your help. 
> 

> Eric has been working towards upgrading all the suns to 4. 1 .3, but I'm 

> not sure how close he is to being able to do this. Is the license 

> node locked to that machine? If not, we are running 4. 1 .3 on our 
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> spare 10 machines. Although these are very busy most of the time 

> running jobs related to Euteipe tapeout, you could run jobs on 

> godzilla in the background if you nice them down so they only soak up 

> otherwize idle cycles. Godzilla is a dual processor machine with each 

> processor 2-3x a spare 2. 
> 

>Tim 

> 

> 

> End Included Message 

> 
> 


Exhibit C8 


Page 385 of 598 


From: philip microunity.com 

Sent: Monday. November 14, 1994 2:24 PM 

To: 'Jean-Yves Michel'; 'tbr@thalia'; 'bilt@thalia'; 'graham@thalia'; 'tom@thalia'; 'noel@thalia' 

Cc: 'hestia@thalia' 

Subject: Re: hestia power planes 


At 1:22 PM 11/11/94 -0800, Jean- Yves Michel wrote: 

>Here is the latest proposal, pending a final OK from Tom and Philip on 
>the pcb stack-up: 

>we will have 2 seperate power/gnd planes, one for Euterpe and the SDRAM 
>and one for Calliope and peripherals. The calliope planes will be 
L- shaped 

>and the other one will be closer to a rectangle. 


> . . .... calliope planes 

> CALLIOPE . euterpe/ SDRAM planes 


DC /DC 


SDRAM 


3.3V 
X 


GND 
X 


>There will be a small supply voltage difference between euterpe and 
>calliope due to IR drop but the differential interface should not be 
affected. 

> 

>In order to have these 4 planes, we will have the following PCB stack-up: 

> 

> component .5oz 

> 26Tnils dielectric 

> power 1 2oz 

> 2mils dielectric 

> ground 1 2oz 

> 6mils dielectric 

> ground 2 2oz 

> 2mils dielectric 

> power 2 2 ox 

> 26mils dielectric 

> solder . 5oz 


>outside the outlined area, 
>differently to carry power 
>planes, shields 
and 

>chassis ground planes. 


the 4 internal layer will be used 

(3.3, 5 and 12V), current carrying ground 


>If you have any object ion ^ 
>layout will be done this week-end 
>finalized by the end of the day. 


raise your voice immediately. A lot of 

so the power plane scheme should be 


> Jean -Yves 
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HADCO has replied and have no problem with the PCB construction as proposed by Jean-Yves. 
Philip 
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From: hopper (Mark Hofmann) 

Sent: Monday, November 14, 1994 3:47 PM 

To: 'Geert Rosseel' 

Subject: Re: Rebuild of sub-blocks in Euterpe snapshot 


Geert Rosseel writes: 
[snip] 

NB : Timing problems (exit status 2) 

I had a look at this. Billz has checked in his new design but I don't think the control 
file {nb_control.pim) is up-to-date. He has volunteered to work on this. 

I am working on a placement and timing of ICC. I think I will have something by late 
tonight or tomorrow morning. 

-mark 
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Subject: 


Sent: 

To: 

Cc: 


From: 


hopper (Mark Hofmann) 

Monday, November 14, 1994 4:13 PM 

'Geert Rosseel' 

'briani (Brian Lee)'; 'ong (Warren R. Ong)' 
Re: nb array tinr)ing 


Geert Rosseel writes: 


Hi, 


NB fails timing because of the EA register file. It has > 2000 hard errors, 

I guess some numbers must not have regenerated correctly. Can you look at this, please 

■p 

The outputs are in the Euterpe snapshot : 
/n/auspex/s41/euterpe-snapshot/euterpe/verilog/bsrc/nb/gards 
EA cells should still have resistor code 5 . 
Are they getting code 6? How do we model this? 
-mark 
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Subject: 


Sent: 

To: 

Cc: 


From: 


wampler (Kurt Wampler) 

Monday. November 14, 1994 7:40 PM 

'paulp' 

'al'; 'cadettes'; 'geert'; 'tbr"; 'vo' 
Euterpe perforation treatment 


Hello, Paul - 

Just so this issue doesn't fall through a crack: we need some perforation guidelines for 
Euterpe. As things currently stand, we have a baseplate snapshot, but nothing has yet 
been done to deperf orate it it's still based on cells which contain perforations that 
are compliant with the last issue of the design rules. 

The deperf oration of Calliopel used the following scheme: 

1) We hand- edited cells which had a relatively high rep count and removed 
the perforations -- approximately 130 cells. 

2) We ran a Dracula flow to synthesize a deperf oration cell which, 

when overlaid on the original layout, eliminated the rest of the perfs. 


1) Should we install the (13 0) deperf orated baseplate cells in the proteus 
area, making them official for Euterpe and future baseplates? 

2) Are infinite sheets of metal really acceptable? (If not, then we need 
to define new perforation parameters.) 

3) What dimension should we use for the smallest allowable rectangular 
perforation? How about donut/f eedthrough perfs? 

Since baseplate DRC/LVS has commenced, the time is ripe to propagate those deperf edits, 
if we're going to do it. 


Questions : 


- Kurt 
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Subject: 


Sent: 

To: 

Cc: 


From: 


paulp (Paul Poenisch) 

Monday, November 14, 1994 8:38 PM 

'Kurt Wampler' 

'al (Albert Matthews)'; 'cadettes'; 'geert (Geert Rosseel)'; 'tbr (Tim B. Robinson)'; 'vo (Tom Vo)' 
Re: Euterpe perforation treatment 


> Kurt Wampler writes: 
> 

> Hello, Paul - 
> 

> Just so this issue doesn't fall through a crack: we need some 
perforation 

> guidelines for Euterpe. As things currently stand, we have a 

> baseplate snapshot, but nothing has yet been done to deperf orate it -- 
> it ' s still based on cells which contain perforations that are 

> compliant with the 
last 

> issue of the design rules. 
> 

> The deperf oration of Calliopel used the following scheme: 
> 

> 1) We hand-edited cells which had a relatively high rep count and 
removed 

> the perforations -- approximately 130 cells. 
> 

> 2) We ran a Dracula flow to synthesize a deperf oration cell which, 

> when overlaid on the original layout, eliminated the rest of the 
perf s . 

> 

> Questions: 
> 

> 1) Should we install the (130) deperf orated baseplate cells in the 
proteus 

> area, making them official for Euterpe «ind future baseplates? 

If the current base plate has the 0.5 urn square perforations we need to fill them in. I 
think we should replace them with larger perforations where we can, see below. 

> 

> 2) Are infinite sheets of metal really acceptable? (If not, then we 
need 

> to define new perforation parameters . ) 

We don't know the answer to this yet but ray gut feel is that infinite sheets will cause 

some problems. We just can't prove it yet. 

> 

> 3) What dimension should we use for the smallest allowable rectangular 

> perforation? How about donut/f eedthrough perf s? 

I've discussed this with all and K.Y., it looks like 1.0 um square perforations are OK, 
0.5 um square pars are not OK and we don't know about the values in between. I think that 
we will be going with a 1.0 um minimum dimention on perforations in the future. I'm going 
to have to talk with Haim about some sort of rule that forbids 0.5 um wide perforations 
but allows 0.5 um wide spaces between lines (probably some variation on the notch rule we 
came up with for poly lines. 
> 

> Since baseplate DRC/LVS has commenced, the time is ripe to propagate 
those 

> deperf edits, if we're going to do it. 


> 


> - Kurt 


> 


I agree. 


Paul. 
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From: 


tbr 


To: 


Sent: 


Subject: 


Cc: 


Monday, November 14, 1994 9:20 PM 
'geerf ; 'bpw'; 'rich'; 'craig' 
'mnemo*; "warren' 
i/o byte 


Follow Up Flag: Follow up 
Flag Status: Red 

I think we have more problems. Does the clock input in the current 
I/O byte have a flop the same as the data bits? If it does we are not 
using it in Euterpe/Calliope. If it doesn't we have a problem on 
Mnemo. This is because we currently rely on the dual outputs of the 
inbound side to determine the odd vs even bytes. Once the sampling 
clock is doubled up, and we only use one of the 2 paths we will use 
that bit of information. We need to be able to sample the clock just 
as a data bit in order to pass this information through. 

Suppose we solve that one, possibly by adding in another flop, then 
Marie Warren raises another issue for testing with the PLL bypassed. 

In this case we still need a sofa clock at 2x the channel clock. 
In an earlier discussion with Mark, we had erroneously concluded that 
we would handle this on the tester by providing vectors with a 2x 
clock, suitably skewed. This canno work, because again we will have 
no way to recover the 9th bit If we feel it is important to be able 
to test with the PLL bypassed, then we will need to add an additional 
input path to supply a 2x clock when in bypass mode. This should be 
straightforward because we already have the 'cli' custom block 
available. 


Tim 
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Sent: 

To: 

Cc: 


Subject: 


From: 


graham (Graham Y. Mostyn) 
Monday. November 14, 1994 9:31 PM 
'hestia' 
'graham' 

Netlist meeting minutes 


Minutes of PC board netlist meeting, Monday, Nov 14: 

* Goal for Gerber plots distributed and ready for review is Thursday 11/17, at 3pni. 

* Plan for final ECOs is Tuesday 11/15 noon. (Later changes will significantly delay DRCs 
and Gerber . ) 

1} Transmitter component change and prt change to be completed 
(arya/ras) by 11/15. 

2) Sense lines from RO power supply; add connection traces with jumper to Euterpe or 
Calliope, with initial jumper set to Euterpe, (arya/woody) 

3} 24v/-5v switching converters. Layout to be completed using existing schematic, 
although noise performance unacceptable. 
Layout guidelines and review; noel . 

4) "Thieving pattern" to be added by Hadco. Philip to identify location for vendor. 
Also, Philip to develop board level fiducials. 

5) Define chassis ground around dc/dc converter, aind tie audio/video/S video/IR connector 

grounds to chassis ground, 
(tbe/noel) ; verilog changes - woody. 

6) Final mechanical verification with solid modeller (tbe) 

7) Define topside castings (arya/tbe) 

8) Develop reference designators (dan albers) . Back- annotation not currently supported, a 
work-around required for component labelling on board. 

9) S video prt; slots on component do not appear to match board; noel/patty to 
investigate . 

10) Vias to be placed tieing chip substrate to ground 
( arya /graham ) 
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From: geert (Geert Rosseel) 

Sent: Monday, November 14. 1994 10:57 PM 

To: 'bpw*; 'stick'; Vo' 

Cc: 'tbr* 

Subject: Euterpe custom block interfaces 

Hi, 

I am a bit worried about the interfaces from the custom blocks to the sofa on 
Euterpe. I think the following things should be reviewed : 

1 . Clock connection from the sofa to the custom blocks. This is only 
for the register file and TLB. The layout of Euterpe should be 
reviewed to check the strength of this connection. We should have 
made strong connections, but it should be independently checked. 

2. Power connections to the custom blocks. Where do the blocks get their 
powre from : nominally and under test ? Are these connections 
strong enough, are there weak links ? This too should be checked on 
the Euterpe layout. 

3. Timing : ttie powerlevels of the interfaces should be checked to the 
custom blocks ... The best way to do this is probably to independently 
derive from the timing tables what strength is needed and then check 
if the strengths we actually have are adequate. 

We are working on automating all three of the above interface checks, but I am pretty 
sure we're not going to have thsi implmented before Euterpe tape-out Can 
you please spend some time checking the above Items and make sure we haven't made 
a misatke in assembly of the chip ? 

If you think something else should be checked, please let us know. 


Thank's 
Geert 
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From: vanthof (vant) 

Sent: Monday. November 1 4, 1 994 11 :00 PM 

To: 'Paul Poenisch' 

Cc: 'wampler (Kurt Wampler)'; 'cadettes'; 'tbr (Tim B. Robinson)'; 'al (Albert Matthews)'; 'geert 

(Geert Rosseel)' 
Subject: Re: Euterpe perforation treatment 


Paul Poenisch writes: 
> 

>I've discussed this with all and K.Y., it looks like 1.0 urn square 
perforations 

>are OK, 0.5 urn square pers are not OK and we don't know about the 

>values 
in 

>between. I think that we will be going with a 1.0 urn minimviin dimention 
on 

>perf orations in the future. I'm going to have to talk with Haim about 

some 

>sort of rule that forbids 0.5 urn wide perforations but allows 0 . 5 urn 
>wide spaces between lines (probably some variation on the notch rule we 
>caine 
up with 

>for poly lines. 

When you refer to "forbids 0.5 um wide perf ©rations but allows 0.5 urn wide spaces", are 
you thinking of small square holes less than 1 um on a side? 

If so, then this is actually a very simple check to impliment. In fact, it's a 
simplification of the check for allowable pedestal sizes . 

Dave 

Dave Van't Hof vanthof ©microunity . com MicroUnity Systems Engineering, 
Inc . 

"What rolls down stairs, alone or in pairs, rolls over the neighbor's dog? 

What's great for a snack and fits on your back? It's log, log, log I" 
LOG from BLAMMOl (tm) All kids love Log! ttincluce 
<std disclaim. h> 
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From: geert (Geert Rosseel) 

Sent: Monday, November 1 4, 1 994 1 1 :09 PM 

To: 'biir; 'ong'; 'tbr" 

Subject: iobyte 


Hi, 

On one of the Euterpe byte-channels, the input section is 
pretty far away fron the SOFA, hidden behind the D-Cache. 

Is there a problem in the timing of the signals coming out 
of the byte-channel into the SOFA, if these signals have a 
varying load-capacitance ? These signals have already been 
clocked by the quadrature clock and run from the byte-channel 
into lO . 

Geert 
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From: geert (Geert Rosseel) 

Sent: Monday, November 1 4, 1 994 1 1 :42 PM 

To: 'biliz'; 'brianl'; 'dickson'; 'mws'; 'tbr"; Vo'; 'woody' 

Cc: 'hopper" 

Subject: Rebuild of sub-blocks In Euterpe snapshot 


Hi, 

I reran in the snapshot all the blocks that 
have run before. I used the new timing 
numbers (power ♦ 1.2) : 

AU Timing problems (exit status 2) 

CC Placement problems 

CDIO : O.K. 

CJ O.K. 

CK O.K. 

CP O.K. 

CTIOD : O.K. 

CTIOl : Timing problems (exit status 2) 

DR : O.K. 
DRIO : O.K. 

ES : Timing problems (No convergence after 8 iter.) 

GF O.K. 

GT : O.K. 

HC Placement problems 

lO O.K. 

LT : O.K. 

MC O.K. 

MST : O.K. 

NB : Timing problems (exit status 2) 

RG : O.K. 

SR O.K. 


Geert 
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From: tbr 

Sent: Tuesday, November 1 5, 1 994 1 :02 AM 

To: 'geert (Geert Rosseel)' 

Cc: 'bpw'; 'lisar'; 'stick'; 'vo' 

Subject: Euterpe custom block interfaces 
Follow Up Flag: Follow up 

Flag Status: Red 


Geert Rosseel wrote (on Mon Nov 14): 


Hi, 

I am a bit worried about the interfaces from the custom blocks to the sofa on 
Euterpe. I think the following things should be reviewed : 

1 . Clock connection from the sofe to the custom blocks. This is only 
for the register file and TLB. The layout of Euterpe should be 
reviewed to check the strength of this connection. We should have 
made strong connections, but it should be independently checked. 

2. Power connections to the custom blocks. Where do the blocks get their 
powre from : nominally and under test ? Are these connections 
strong enough, are there weak links ? This too should be checked on 

the Euterpe layout. 

3. Timing : the powerlevels of the interfaces should be checked to the 
custom blocks ... The best way to do this is probably to independently 
derive from the timing tables what strength is needed and then check 
if the strengths we actually have are adequate. 

We are working on automating all three of the above interface checks, but 1 am pretty 
sure we're not going to have thsi implmented before Euterpe tape-out. Can 
you please spend some time checking the above items and make sure we haven't made 
a misatke in assembly of die chip ? 

If you think something else should be checked, please let us know. 

We also need to check the algorithmic side of the timing interfaces on 
all multi-cycle paths. Lisar has this in hand, but we may want a 
final review that we have all cases covered. 

Tim 
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Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 
Tuesday, Novennber 15, 1994 1:02 AM 


'geert (Geert Rosseel)' 
'bpw'; 'lisar'; 'stick'; Vo' 


Subject: 


Euterpe custom block interfaces 


Geert Rosseel wrote (on Mon Nov 14} : 


Hi, 


I am a bit worried about the interfaces from the custom blocks to the sofa on 
Euterpe. I think the following things should be reviewed : 

1. Clock connection from the sofa to the custom blocks. This is only 
for the register file and TLB. The layout of Euterpe should be 
reviewed to check the strength of this connection. We should have 
made strong connections, but it should be independently checked. 

2. Power connections to the custom blocks. Where do the blocks get their 
powre from : nominally and under test ? Are these connections 
strong enough, are there weak links ? This too should be checked on 
the Euterpe layout. 

3 . Timing : the powerlevels of the interfaces should be checked to the 
custom blocks . . . The best way to do this is probably to independently 
derive from the timing tables what strength is needed and then check 
if the strengths we actually have are adequate. 

We are working on automating all three of the above interface checks, but I am pretty 
sure we're not going to have thsi implmented before Euterpe tape-out. 

Can 

you please spend some time checking the above items and make sure we haven't made 
a misatke in assembly of the chip ? 

If you think something else should be checked, please let us know. 

We also need to check the algorithmic side of the timing interfaces on all multi -cycle 
paths. Lisar has this in hand, but we may want a final review that we have all cases 
covered. 


Tim 
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From: tbr 

Sent: Tuesday. November 1 5, 1 994 1 : 07 AM 

To: 'geert (Geert Rosseel)' 

Cc: 'bill'; 'ong' 

Subject: iobyte 

Follow Up Flag: Follow up 

Flag Status: Red 


Geert Rosseel wrote (on Mon Nov 14): 


Hi. 

On one of the Euterpe byte-channels, the input section is 
pretty far away fron the SOFA, hidden behind the D-Cache. 

Is there a problem in the timing of the signals coming out 
of the byte-channel into the SOFA, if these signals have a 
varying load-capacitance ? These signals have already been 
clocked by the quadrature clock and run from the byte-channel 
into lO . 

I would not expect a problem, because we have generous clock skew 
tolerance. We need a spice check on the prop delay of the worst path 
though to make sure the driver is high enough powered. 

Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr {Tim B. Robinson) 

Tuesday, November 15, 1994 1:07 AM 

'geert (Geert Rosseel)' 

'bill'; 'ong' 

iobyte 


Geert Rosseel wrote (on Mon Nov 14) : 


Hi 


On one of the Euterpe byte- channels/ the input section is 
pretty far away fron the SOFA, hidden behind the D- Cache. 

Is there a problem in the timing of the signals coming out 
of the byte-channel into the SOFA, if these signals have a 
varying load- capacitance ? These signals have already been 
clocked by the quadrature clock and run from the byte- channel 
into lO - 

I would not expect a problem, because we have generous clock skew tolerance. We need a 
spice check on the prop delay of the worst path though to make sure the driver is high 
enough powered. 


Tim 
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From: tbr 

Sent: Tuesday, November 1 5, 1 994 1 :08 AM 

To: 'geert (Geert Rosseel)' 

Cc: 'blllz'; 'brianl'; 'dickson'; 'hopper'; 'mws'; Vo'; 'woody' 

Subject: Rebuild of sub-blocks in Euterpe snapshot 
Follow Up Flag: Follow up 

Flag Status: Red 

Geert Rosseel wrote (on Mon Nov 14): 
Hi. 

I reran in the snapshot all the blocks that 
have run before. I used the new timing 
numbers (power * 1.2) : 

Do you have comparative atom counts? 
Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Tuesday, November 15, 1994 1:08 AM 

'geert (Geert Rosseel)' 

'biliz'; 'brianl'; 'dickson'; 'hopper'; 'mws'; Vo'; 'woody' 
Rebuild of sub-blocks In Euterpe snapshot 


Geert Rosseel wrote (on Men Nov 14) : 


Hi, 


I reran in the snapshot all the blocks that 
have run before. I used the new timing 
numbers (power * 1 . 2 ) 

Do you have comparative atom counts? 

Tim 
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From: geert (Geert Rosseel) 

Sent: Tuesday, November 1 5, 1 994 1 :24 AM 

To: tbr' 

Cc: 'biliz*; 'briani'; 'dickson'; 'hopper'; 'mws'; Vo'; 'woody' 
Subject: Re: Rebuild of sub-blocks in Euterpe snapsliot 

I just rebuild the topi eve) and it's not looking as good as I had 
hoped. However, when 1 let it power-down the interfaces (based 
on the nof file information), I save another 10% in ato,s. I 
am now in the process of generating power.tab. local files for 
all the sub-blocks based on my top-level. 

Geert 
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From: Warren R. Ong [ong@ares] 

Sent: Tuesday, November 15, 1994 6:32 AM 

To: 'Mark Hofmann' 

Cc: 'tbr^aphrodite'; 'hopper@aphrodite'; 'brianl@aphrodite'; 'geert@LOCAL'; 'ong@aphrodite'; 

'Alan Corry' 

Subject: Re: nb array timing 


>FroTn Mark. Hofraann . . . 
® 

@ Tim B. Robinson writes: 


@ Mark. Hofmann wrote (on Tue Nov 15) : 

® Geert Rosseel writes: 

® 

@ Ea cells will also run from code 6. 

@ There is no way we can sepertate them out 

® from regular sofa. 
® 

® Umm. . . 

® This is a major re-design for Warren. Do we have time? 

® 

® Why is that? I assume they will get faster, but do we expect races 


to 

@ develop? My assumption in promoting this change is that we would not 
@ have to redesign enything, we just give up a little optimality. 

@ 

® Perhaps I over- spoke. I do think that simulations will need to be run ® to confirm 
proper operation at rcd-6, but these should be done in any @ event (for most resistor 
codes , I would think) . 
® 

YeS/ all of the exlax arrays will be re- simulated. There is an inherent race between the 
write wordline and the write bitlines. 

We always want the write wordline to switch first. I do not anticipate any problems with 
red 6. 

For euterpe, I only recall 2 arrays: nbal6x64 and nbd32x64. Are there any others? 

Thanks , 
Warren. 
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From: Mark Hofmann [hopper@rhodan] 

Sent: Tuesday, November 1 5, 1 994 7:36 AM 

To: 'Warren R. Ong' 

Cc: 'tbrigaphrodite'; •hopper@aphrodite'; 'brianl@aphrodite'; 'geert@LOCAL'; 'ong@aphrodite'; 

'agc@ares' 

Subject: Re: nb array timing 


Warren R. Ong writes: 

Yes, all of the exlax arrays will be re- simulated. There is an 
inherent race between the write wordline and the write bitlinea. 
We always want the write wordline to switch first. I do not 
anticipate any problems with red 6. 

For euterpe, I only recall 2 arrays: nbal6x64 and nbd32x64. Are 
there any others? 

Thanks , 
Warren . 

Those are the 2 that I know of . 
"hopper 
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Subject: 


Sent: 

To: 

Cc: 


From: 


solo (John Campbell) 

Tuesday, November 15, 1994 9:27 AM 

'Tim B. Robinson' 

'geert (Geert Rosseel)'; 'bpw (B. P. Wong)'; 'rich (Rich McCauley)'; 'craig (Craig Hansen)'; 
'mnemo'; 'warren (Mark Warren)' 
Re; i/o byte 


as Tim B. Robinson was saying 


..I think we have more problems. Does the clock input in the current ..I/O byte have a 
flop the same as the data bits? if it does we are not . .using it in Euterpe/Calliope. If 
it doesn't we have a problem on ..Mnemo. This is because we currently rely on the dual 
outputs of the ..inbound side to determine the odd vs even bytes. Once the sampling 
..clock is doubled up, and we only use one of the 2 paths we will use ..that bit of 
information. We need to be able to sample the clock just . .as a data bit in order to pass 
this information through. 

..Suppose we solve that one, possibly by adding in another flop, then ..Mark Warren raises 
another issue for testing with the PLL bypassed. 

..In this case we still need a sofa clock at 2x the channel clock. 

..In an earlier discussion with Mark, we had erroneously concluded that ..we would handle 
this on the tester by providing vectors with a 2x ..clock, suitably skewed. This canno 
work, because again we will have ..no way to recover the 9th bit. If we feel it is 
important to be able . .to test with the PLL bypassed, then we will need to add an 
additional . . input path to supply a 2x clock when in bypass mode . This should be 
..straightforward because we already have the 'cli' custom block ..available. 


Tim 


i don't see how we can debug without a bypass clock. 


regards , 

solo a.k.a. John Campbell 


X516 
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From: biliz (Bill Zuravleff) 

Sent: Tuesday, November 15, 1994 9:48 AM 

To: 'geert' 

Subject: Re: Rebuild of sub-blocks in Euterpe snapshot 


Where might we find the gards/design. stat and other such files to help you correct these 
problems? 

billz 
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From: Eric Murray [ericnn@MicroUnity.com] 
Sent: Tuesday, November 15, 1994 10:01 AM 
To: 'sysadm@MicroUnity.com' 
Subject: disk usage report 


For directories over ICQ megs: 

user's info* 


bri&nl 

I4ZZ 

hopper 

1 1 <A 

chip 

1029 

two 


dickson 

907 

craig 

880 

iDr 

8*74 
O f*t 

geert 

547 

JSW 


gmo 

595 

rozen 

575 

vanthof 


11 

loo 

vijay 

485 

brendan 

479 

sandeep 

471 

rocky 

AASi 


UO 

brian 

417 

wampler 


ken 

338 

doi 

300 

luip 

Zoo 

lur 


age 

281 

tbe 

270 

torn 

268 

hchu 

259 

wingaru 

247 

ras 

234 

veena 

231 

hessam 

231 

fung 

220 

peter 

206 

bill 

203 

rich 

202 

jeffin 

197 

iimura 

197 

haim 

190 

lisar 

189 

gregg 

185 

mws 

184 

a! 

181 

billz 

174 

Vandyke 

173 

ericm 

172 

solo 

169 

cox 

160 

bpw 

155 
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guarino 

153 

lisa 

151 

randy 

142 

woody 

140 

karzes 

140 

chuck 

139 

jeff 

135 

fembro 

134 

dane 

132 

octtools 

130 

albers 

127 

kgk 

127 

tomho 

127 

mikew 

119 

yves 

117 

ong 

112 

hayes 

Ul 

paulb 

109 

larryk 

103 


packages info: 


chip-euterpe-buil 2039 

calliope 

1579 

news 

1421 

euterpe-verify 

1011 

chip-archive 

871 

orchis_snap 

811 

chip-proteus 

787 

calIiope-disk2 

730 

losf-build 

685 

ptolemy 

652 

soft-src 

639 

cadence 

636 

archives 

603 

sun 

568 

cadence. hp 

552 

calliope 1-fractur 487 

chip-calliope 

484 

soft 

477 

chip-terpsichore 475 

sgi 

377 

xllr5_ken_p26 329 

castor-retry 

325 

bosf-build 

323 

chip-archive- terp 3 1 8 

calliope-overflow 297 

mips-4,52 

282 

osf 

260 

chip-archive-mnem 259 

Xllr4 

228 

bsd 

222 

cadence_doc 

221 

synopsys 

216 

cadence doc 9402 215 

budtool_db 

190 

budtool 

181 

Motif 

177 

mechanica 

164 

sgi5 

152 
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bigtmp 147 

ucberl 147 

ikos 147 

vlsi.v8r4_2 145 

proe_tmp 138 

ftp 134 

khoros 134 

proe_13.0 134 
calliope- verify 132 

iimura.be 128 

gnu 125 

lib 121 

bsd43 115 

frame-4.0.3 115 

svr4 1 14 

XllrS 111 

chip-mdunit I OS 

motif 1.2 101 


machine user megs package megs total megs max capacity % used 

auspex 20262 19051 39313 59499 66% 

nima 3697 2244 5942 9428 63% 

rhea 215 1602 1817 2484 73% 

gaea 5 1803 1808 1780 101% 

cronus 612 2214 2827 6208 45% 

auspex rama rhea gaea cronus: 

24791 26914 51707 79399 65% 
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From: paulp (Paul Poenisch) 

Sent: Tuesday, November 1 5, 1 994 1 0:29 AM 

To: Vanf 

Cc: 'warn pier (Kurt Wampler)'; 'cadettes'; 'tbr (Tim B. Robinson)'; 'al (Albert Matthews)'; 'geert 

(Geert Rosseel)' 
Subject: Re: Euterpe perforation treatment 


> Dave van't Hof writes: 

> Paul Poenisch writes: 

> > 

> >l've discussed this with all and K.Y., it looks like 1.0 urn square 
perforations 

> >are OK, 0.5 urn square pers are not OK and we don't know about the 
values in 

> >between. I think that we will be going with a 1.0 urn minimum 

> >dimention 

on 

> >perf orations in the future. I'm going to have to talk with Haim 

> > about 
some 

> >sort of rule that forbids 0 . 5 urn wide perforations but allows 0.5 urn 
wide 

> >spaces between lines (probably some variation on the notch rule we 

> >came 
up with 

> >for poly lines. 

> When you refer to "forbids 0.5 urn wide perferations but allows 0.5 urn 
wide 

> spaces", are you thinking of small square holes less than 1 urn on a 
side? 

> If so, then this is actually a very simple check to impliment. In 

> fact , 

> it's a simplification of the check for allowable pedestal sizes. 
> 

> Dave 

> - - 

> Dave Van't Hof vanthof@microimity.com MicroUnity Systems 
Engineering, Inc. 

> "What rolls down stairs, alone or in pairs, rolls over the neighbor's 
dog? 

> What's great for a snack and fits on your back? It's log, log, logl" 

> LOG from BLAMMO! (tm) All kids love Log! #incluce 
< std_disclaim . h> 

> 

Actually it's a little more complex than that. 0 . 5 um wide by X urn long perforations are 
also a problem, we don't know what X is but it's definately larger than 3 um. We would 
like to eliminate all holes in the metal that have either diraention less than 1.0 um. But 
we want to allow 0 . 5 um spaces where the ends are not closed off (which the vast majority 
should be) . Cases where a metal space is formed by a fork in a metal line which later 
widens are a little harder to call at this point, but we probably don't want the minimum 
space to extens for longer than some fixed, but currently unknown, distance. 

Paul. 
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From: vanthof (vant) 

Sent: Tuesday, November 1 6, 1 994 1 0:34 AM 

To: 'Paul Poenisch' 

Cc: 'vanthof@acteon.microunity.com'; 'wampler (Kurt Wampler)'; 'cadettes'; 'tbr (Tim B. 

Robinson)'; 'al (Albert Matthews)'; 'geert (Geert Rosseel)' 
Subject: Re: Euterpe perforation treatment 


Paul Poenisch writes: 

> 

>> 

>Actually it ' s a little more complex than that. 0.5 um wide by X um 
>long perforations are also a problem, we don't know what X is but it's 
def inately 

>larger than 3 um. We would like to eliminate all holes in the metal 

>that 

have 

>either dimention less than 1.0 ura. But we want to allow 0.5 urn spaces 

where 

>the ends are not closed off (which the vast majority should be) . Cases 
where 

>a metal space is formed by a fork in a metal line which later widens 
>are 

a 

>little harder to call at this point, but we probably don't want the 
minimum 

> space to extens for longer than some fixed, but currently unknown, 
distance. 

> 

>Paul. 


Thanks. The current hole filling algorithm looks for holes which are less than 12 square 

microns in area, plus a few other requirements. 

Converting 

that flow to do a drc check is feasable once some numbers can be pinned down. 
Dave 


Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, 
Inc. 

"What rolls down stairs, alone or in pairs, rolls over the neighbor's dog? 

What's great for a snack and fits on your back? It's log, log, logi" 
LOG from BLAMMO! (tm) All kids love Log! #incluce 
<std disclaim. h> 
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Subject: 


Sent: 

To: 

Cc: 


From: 


brianl nnicrounity.com (Brian Lee) 
Tuesday, November 15, 1994 10:54 AM 
'Mark Hofmann' 

'geert@MicroUnity.com'; 'ong (Warren R, Ong)' 
Re: nb array timing 


Mark Hofmann writes: 


Geert Rosseel writes: 


Hi 


NB fails timing because of the EA register file. It has > 2 000 hard 
errors, 

I I guess some numbers must not have regenerated correctly. Can you 
look at this, please ? 

I The outputs are in the Euterpe snapshot : 

I /n/auspex/s4l/euterpe- snapshot /euterpe/verilog/bsrc/nb/gards 
|ea cells should still have resistor code 5. 
I Are they getting code 6? How do we model this? 

Hmmmtn. Two things. The snapshot last failed in ged/ea before it 
re- ran any of the exlax cells. Whatever is there is from before. 

However, when I restart it they will extract there numbers from similar xb cells and thus 
get code 6 ... 


Brian Lee brianl@microvinity.com 
MicroUnity Systems Engineering (408) 734-8100 
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From: bill (William Herndon) 

Sent: Tuesday. November 1 5, 1 994 11 :32 AM 

To: 'geert'; 'tbr* 

Cc: 'ong' 

Subject: Re: iobyte 


> From tbr Mon Nov 14 23:06:55 1994 

> Date: Mon, 14 Nov 1994 23:06:51 -0800 

> From: tbr (Tim B. Robinson) 

> To: geert (Geert Rosseel) 

> Cc: bill, ong 

> Subject: iobyte 

> Content -Length: 64 0 


> Geert Rosseel wrote (on Mon Nov 14) : 


> Hi , 
> 

> On one of the Euterpe byte -channels, the input section is 

> pretty far away fron the SOFA, hidden behind the D-Cache; 

> 

> Is there a problem in the timing of the signals coming out 

> of the byte-channel into the SOFA, if these signals have a 

> varying load- capacitance ? These signals have already been 

> clocked by the quadrature clock and run from the byte- channel 

> into 10 . 
> 

> I would not expect a problem, because we have generous clock skew 

> tolerance. We need a spice check on the prop delay of the worst path 

> though to make sure the driver is high enough powered. 

> 

> Tim 


I have a spice framework that i used for calliope that can be used for this probably with 
some small modification. The actual circuits and identification of parasitics is, however 
questionable. Nobody seems to own the whole thing. 

A number of people have been involved, tbr, alan, rich dickson. I am very concerned about 
something falling in a crack here because we don't have some sort of unified circuit 
description. 
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From: 
Sent: 
To: 

Subject: 


lisa 

Tuesday, November 15, 1994 11:41 AM 
'software-checkins-dist' 
gnu-tools/sim/terp v_mem.c 


U^Kiate of /p/cvsroot/gnu- tools/ Sim/ terp 

In directory calliope: /N/auspex/root/s6/lisa/src/gnu-tools/sim/terp 

Modified Files: 

v_niem . c 
Log Message: 

Removed old way of enabling translation (by writing to first Itlb) . 
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From: 
Sent: 
To: 

Subject: 


lisa 

Tuesday, November 15, 1994 11:48 AM 
'software-checkins-dist' 
gnu-tools/sim/terp events, c 


update of /p/cvsroot/gnu-tools/sim/terp 

In directory calliope: /N/auBpex/root/s6/lisa/src/gnu- tools/ sim/terp 

Modified Files: 
events . c 
Log Message: 

Cleaned up system_reg_access { ) to be consistent about latency. 

It also is knovm to be fast-on-chip, so it does not need to handle nb stuff. 
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From: Geert Rosseel [geert@godzilla] 
Sent: Tuesday, November 1 5, 1 994 2:37 PM 

To: 'brianl@godzilla'; 'hopper@godzilla'; 'lisar@godzilla'; 'rich^godzilla'; 'tbr@godzilla'; 
'wamp)er@godzilla' 

Cc: 'graham@godziIla' 

Subject: Euterpe PLL's 

Hi, 

We have change the knob-settings on all SOFA to 6, but Rich 
would like to keep the current PLL as is (optimized with a 
knobs etting of 5) 

We've discussed two options : 


-> rebuild the PLL with red = 6 
This is quite a bit of work and Rich likes to keep the 
maigin to go from 5 to 7. 


-> build different sets of libraries at different knob-settings 
We all think this is a good idea because we may need 
the different libraries for other purposes (like Mnemo) 
However, this is going to be a lot of work and probably not 
finished before Euterpe tape-out. 


So, the compromise is : 

Build power .tab files for the PLL sofa that fix the powerievels 
of all the instances in the PLL SOFA. Then, topt will not change 
any of the gates from the current PLL and the resulting SOFA 
should be the same as it is now, independently of what knob setting 
we use. While topt will not change anything, it will still verify 
that the PLL meets timing. 
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From: 
Sent: 
To: 


Cc: 

Subject: 


Kurt Wampler [wampler@thoas] 
Tuesday, November 15, 1994 3:45 PM 

'bhani@goclzilla'; 'geert@goclzilla'; 'hopper@godzilla'; 'lisar@godzilla'; 'rich@goclzilla'; 

'tbr@goclzilla' 

'graham@godzilla' 

Re: Euterpe PLL's 


Geert writes: 


> We have change the knob- settings on all SOFA to 6, but Rich would like 
>to keep the current PLL as is (optimized with a knobsetting of 5) 

> 

> We've discussed two options : 
> 

> -> rebuild the PLL with red = 6 

> This is quite a bit of work and Rich likes to keep the 

> margin to go from 5 to 7 . 

Actually, with the speed improving slightly, and the cell footprints 
either staying the same or getting smaller, there's a good chance that 
just re -running the Make would yield a successful build. However, 
keeping the 5:7 margin seems like a compelling reason to want to 
stay with the cell sizes tuned for rcd=5 operation. 

> -> build different sets of libraries at different knob- settings 

> We all think this is a good idea because we may need 

> the different libraries for other purposes (like Mnemo) 

> However, this is going to be a lot of work and probably not 

> finished before Euterpe tape-out. 
> 

> So, the compromise is : 

> 

> Build power. tab files for the PLL sofa that fix the powerlevels of 

> all the instances in the PLL SOFA. Then, topt will not change any of 

> the gates from the current PLL and the resulting SOFA should be the 

> same as it is now, independently of what knob setting we use. While 

> topt will not change anything, it will still verify that the PLL 

> meets timing. 

We can certainly hard- code every single component's power level, but this 
means that the PLL gardswarts won't be able to track any subsequent changes 
in the timing numbers as they are refined. Would it be more robust instead 
to tighten the cycle time target for these gardswarts to get back the 
guardband that would otherwise be lost by going from rcd=5 -> rcd=6 ? I 
think it would be worth a try, since it doesn't involve much effort 
(change one line in the Makefile and re-make) . I guess the major effort 
would be re-doing the SPICE simulation of the final results, although we 
■ could perhaps just diff the power levels of all instances before and after, 
and if they didn't change (or increased) we would know that we kept our 
guardband . 

Further comments? 


- Kurt 
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From: Rich McCauley [rich@pegasus] 

Sent: Tuesday, November 15, 1 994 4:54 PM 

To: 'wampler@thoas' 

Cc: 'brianl@godzilia'; 'geert@godzifla'; 'hopper@godzilla'; 'lisar@godzi|]a'i 'tbr@pegasus' 

Subject: Re: Euterpe PLL's 


It seems that as long as the timing would be checked by topt, leaving them as they 
currently are would be fine. As timing files change, topt should alert us to any timing 
failures . 

rich 


> From wampler®thoas Tue Nov 15 13:44:45 1994 

> Date: Tue, 15 Nov 1994 13:44:41 -0800 

> From: waraplerOthoas (Kurt Wampler) 

> TO: brianl@godzilla, geert@godzilla, hopper@godzilla, lisar@godzilla, 

> rich@godzilla, tbr®godzilla 

> Subject: Re: Euterpe PLL's 

> Cc : graham@godzilla 

> Content -Length: 2153 
> 

> Geert writes: 


> > We have change the knob -set tings on all SOFA to 6, but Rich would 

> >like to keep the current PLL as is (optimized with a knobsetting of 

> >5> 

> > 

> > We've discussed two options : 

> > 

> > -> rebuild the PLL with red = 6 

> > This is quite a bit of work and Rich likes to keep the 

> > margin to go from 5 to 7 , 

> 

> Actually, with the speed improving slightly, and the cell footprints 

> either staying the same or getting smaller, there's a good chance that 

> just re -running the Make would yield a successful build. However, 

> keeping the 5:7 margin seems like a compelling reason to want to 

> stay with the cell sizes tuned for rcd=5 operation. 
> 

> > -> build different sets of libraries at different Icnob- settings 


> > We all think this is a good idea because we may need 

> > the different libraries for other purposes (like Knemo) 

> > However, this is going to be a lot of work and probably not 

> > finished before Euterpe tape-out. 

> > 


> > So, the compromise is : 

> > 

> > Build power. tab files for the pll sofa that fix the powerlevels of 

> > all the instances in the PLL SOFA. Then, topt will not change any 

> > of the gates from the current PLL and the resulting SOFA should be 

> > the same as it is now, independently of what knob setting we use. 

> > While topt will not change anything, it will still verify that the 

> > PLL meets timing. 
> 

> We can certainly hard- code every single component's power level, but 
this 

> means that the PLL gardswarts won't be able to track any subsequent 
changes 

> in the timing numbers as they are refined. Would it be more robust 
instead 

> to tighten the cycle time target for these gardswarts to get back the 

> cfuardband that would otherwise be lost by going from rcd>5 -> rcd"6 ? 
I 
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> think it would be worth a try, since it doesn't involve much effort 

> (change one line in the Makefile and re-tnake) . I guess the major 
effort 

> would be re-doing the SPICE simulation of the final results, 

> although 
we 

> could perhaps just diff the power levels of all instances before and 
after, 

> and if they didn't change (or increased) we would know that we kept 
our 

> guardband. 

> 

> Further comments? 
> 

> - Kurt 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Tim B. Robinson [tbr@aphrodite] 
Tuesday, November 15, 1994 5:11 PM 
'Warren R. Ong' 

'Alan Corry'; •brianl@aphrodite'; 'geert@LOCAL'; 'hopper@aphrodite'; 'Mark Hofmann'; 

'ong@aphrodite' 

Re: nb array timing 


Warren R. Ong wrote (on Tue Nov 15) : 

Yes, all of the exlax arrays will be re- simulated. There is an 
inherent race between the write wordline and the write bitlines. 
We always want the write wordline to switch first. I do not 
anticipate any problems with red 6. 

How easily can we verify we have no race at any code setting? We certainly intend to 
operate at code 1 in low power standby mode. 

For euterpe, I only recall 2 arrays: nbal6x64 and nbd32x64 . Are 
there any others? 

I think these are the only 2. 
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From: Tom Laidig [tonri@clio] 

Sent: Tuesday, November 1 5, 1 994 5: 1 2 PM 

To: 'Paul Poenisch' 

Cc: Thomas Laidig'; 'Albert Matthews'; 'cadettes@clio'; 'Geert Rosseel'; 'Tim B. Robinson'; 'Tom 

Vo' 

Subject: Re: Euterpe perforation treatment 


Paul Poenisch writes: 

> Kurt Wampler writes: 
> 

> Questions: 

> 

> 1) Should we install the (130) deperf orated baseplate cells in the 
proteus 

> area, making them official for Euterpe and future baseplates? 

If the current base plate has the 0.5 um square perforations we need to 
fill 

I them in. I think we should replace them with larger perforations where 
we 

can, see below. 

> 

> 2} Are infinite sheets of metal really accepteJ^le? (If not, then 

> we 
need 

|> to define new perforation parameters.) 

I 

I We don't know the answer to this yet but my gut feel is that infinite 
sheets 

I will cause some problems. We just can't prove it yet. 
I> 

|> 3) What dimension should we use for the smallest allowable 
rectangular 

> perforation? How about donut/f eedthrough perfs? 

I've discussed this with all and K.Y., it looks like 1 . 0 um square 
perforations 

I are OK, 0.5 um square pers are not OK and we don't know about the 
I values 

in 

[between. I think that we will be going with a 1,0 um minimum dimention 
on 

[perforations in the future. I'm going to have to talk with Haim about 
some 

sort of rule that forbids 0.5 um wide perforations but allows 0.5 um 
wide spaces between lines (probably some variation on the notch rule we 
came 
up with 
for poly lines. 
> 

> Since baseplate DRC/LVS has commenced, the time is ripe to propagate 
those 

> deperf edits, if we're going to do it. 

> 

> - Kurt 
> 

I agree. 
Paul. 


OK, we all agree that we need to do something pronto, but the precise rules are unclear at 
present. So, let me propose a specific plan of action that we can take to try to get much 
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closer to what we want than where we are, hopefully without expending lots of energy doing 
things that won't be necessary. Darts, overripe fruit, etc. are _strongly__ encouraged. 

1) Try to eliminate all holes we know of (except doughnuts around 
f eedthrougha , which obviously can't be eliminated) in the drawn 
data, ignoring any concerns about over- large sheets. Assume 
that the rules limiting sheet size, when they are available, 
will allow enough wiggle room that we can add the holes 
automatically in the back end, without the need for manual 
intervention . 

2) Add a check to the DRC flow for each metal layer (incl ContPed 
and vias, of course) that will flag as an error any hole that 
does not include at least one area of at least lu square. 

3) Worry about anything else later. 


00000 Ooooo 

( _) (_ ) 

1 ( Tom ) I 
(_) L (_) 
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From: tbr 

Sent: Tuesday, November 1 5, 1 994 5: 1 3 PM 

To: 'Geert Rosseel' 

Cc: 'brranl@godzilla'; 'graham@godzilla'; 'liopper@godzilla'; 'lisar@godzilla'; 'rich@godzilla'; 

'wampler@godzilla' 

Subject: Euterpe PLL's 

Follow Up Flag: Follow up 

Flag Status: Red 

Geert Rosseel wrote (on Tue Nov 15): 


Hi, 

We have change the knob-settings on all SOFA to 6, but Rich 
would like to keep the current PLL as is (optimized with a 
knobsetting of 5) 

We've discussed two options : 


-> rebuild the PLL with red = 6 
This is quite a bit of work and Rich likes to keep the 
margin to go from 5 to 7. 


-> build different sets of libraries at different knob-settings 
We all think this is a good idea because we may need 
the diflferent libraries for other purposes (like Mnemo) 
However, this is going to be a lot of work and probably not 
finished before Euterpe tape-out. 


So, the compromise is : 

Build power.tab files for the PLL sofa that fix the powertevels 
of all tiie instances in the PLL SOFA. Then, topt will not change 
any of the gates from the current PLL and the resulting SOFA 
should be the same as it is now, independently of what knob setting 
we use. While topt will not change anything, it will still verify 
that the PLL meets timing. 

Sounds like the right compromize, but given the new timing data 
assumes code 6, how will topt correctly verify timing based on that 
data, given we will actually be operating it with code S? 

Tim 
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Sent: 

To: 

Cc: 


Subject: 


From: 


Tim B, Robinson [tbr@aphrodlte] 
Tuesday, November 15, 1994 5:13 PM 
'Geert Rosseel' 

'brianl@godzilla'; 'graham@godzilla'; 'hopper@godziila'; ')isar@godzilla'; 'rich@godzilla'; 

'wampler@godzi)la' 

Euterpe PLL's 


Geert Rosseel wrote (on Tue Nov 15) ; 


Hi, 


We have change the knob-settings on all SOFA to 6, but Rich 
would like to keep the current PLL as is (optimized with a 
knobsetting of 5) 

We've discussed two options : 


-> rebuild the PLL with red = 6 

This is quite a bit of work and Rich likes to keep the 
margin to go from 5 to 7. 


-> build different sets of libraries at different knob- settings 
We all think this is a good idea because we may need 
the different libraries for other purposes (like Mnemo) 
However, this is going to be a lot of work and probably not 
finished before Euterpe tape-out. 


So, the compromise is ; 

Build power. tab files for the PLL sofa that fix the powerlevels 
of all the instances in the PLL SOFA. Then, topt will not change 
any of the gates from the current PLL and the resulting SOFA 
should be the same as it is now, independently of what knob setting 
we use. While topt will not change anything, it will still verify 
that the PLL meets timing. 

Sounds like the right compromize, but given the new timing data assumes code 6, how will 
topt correctly verify timing based on that data, given we will actually be operating it 
with code 5? 


Tim 
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From: Paul Poenisch [paulp@acteon] 

Sent: Tuesday, November 15, 1994 6:02 PM 

To: 'Tom Laidig' 

Cc: 'Albert Matthews'; 'cadettes@acteon'; 'Geert Rosseel'; Tim B. Robinson': 'Tom Vo' 

Subject: Re: Euterpe perforation treatment 


Tom Laidig writes : 
> 

> OK, we all agree that we need to do something pronto, but the precise 

> rules are unclear at present. So, let me propose a specific plan of 

> action that we can take to try to get much closer to what we want than 

> where we are, hopefully without eacpending lots of energy doing things 

> that won't be necessary. Darts, overripe fruit, etc. are _strongly_ 

> encouraged. 
> 

> 1) Try to eliminate all holes we know of (except doughnuts around 

> f eedthroughs , which obviously can't be eliminated) in the drawn 

> data, ignoring any concerns about over- large sheets. Assume 

> that the rules limiting sheet size, when they are available, 

> will allow enough wiggle room that we can add the holes 

> automatically in the back end, without the need for manual 

> intervention. 
> 

> 2) Add a check to the DRC flow for each metal layer (incl ContPed 

> and vias, of course) that will flag as an error any hole that 

> does not include at least one area of at least lu square. 
> 

> 3) Worry about anything else later. 


> ooooO Ooooo 

> (_)<_) 

> I ( Tom ) I 

> (_) L (_) 
> 

This sounds reasonable. I would suggest that we might want to run some test cases on re- 
perferizing the metal with a larges size hole (say 1.0 um x 1.0 urn) to see if there will 
be any serious problems, like too much reduction in cross sectional area or problems with 
certain width metal lines . 

Paul. 
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From: 
Sent: 
To: 

Subject: 


lisa 

Tuesday, November 15, 1994 6:23 PM 
'software-checklns-dist' 
gnu-tools/sim/terp cycles, c 


Update of /p/cvsroot/gnu-tools/sim/terp 

In directory calliope : /N/auspex/root/s6 /lisa/ src/gnu- tools/ sira/terp 

Modified Files: 
cycles. c 
Log Message: 

- Allocate 2% of text-size in bytes, not in instructions, for from-to arcs. 

- Only realloc tostruct's if new limit is larger than previous one. 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Curtis Abbott [abbott@tatlls] 
Tuesday, November 15, 1994 6:34 PM 
'tbr@tallis' 

'craig@tallis'; 'dickson@tallis' 
esum 


I've gone around most people in my group and couldn't find any ardent lovers of esum. It 
replaces about 15 instructions, so if there's a need for it, it'll definitely be a win. 
People like it, but they're not using it smd don't have specific ideas about how they 
would. 

I'd say if it'll make tapeout happen sooner, you can get rid of it. 


- Curtis 
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From: 
Sent: 
To: 

Subject: 


Jeff Marr |jeffm@kephalos] 
Tuesday, November 15, 1994 7:23 PM 
'euterpe@kephalos' 
faking onchip start address 


As more of real ifetch goes into the design, the current way of forcing execution to begin 
onchip, even though the pc is in rom space, will cease to work. The current way does not 
actually change the pc . 

Already, I have been bitten three times by side-effects of this: 


Any branch- and- link operation loads the real, not faked, 
pc into ro . I think/ hope that I have made sure that no 
pre- or post-event pc's depend on addresses derived from 
a branch and link. There is also a kludge in the SW test 
scaffolding to work around this. 

The IF exception HW currently assumes that an offchip instruction 
address is cacheable - and should have "reasonable" itag entries, 
never mind whether the gtlb indicates that the address is 
in a cacheable page. (I think this is a bug.) This was stopping 
exlOtest from running, and is currently worked around. 

Starting a simulation run with memory management forced on 
runs into the problem above immediately, preventing the 
_V {shortened for verilog) tests from running, 

I spoke with mws today, and he indicated that there no free way to force the reset pc to 
be the start of ibuffer. At the cost of one more 

0/1 generator, a force would be possible, by clever grouping of the O's and I's. Whether 
this would work on zycad is not clear. 

Alternately, we could always 

pay the price of fetching the 6*5 instructions required to branch to the the beginning 
of ibuffer. This is very costly in simulation time. 


Comments? 


jef fm 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Kurt Warn pier [wampler@thoas] 
Tuesday, November 15, 1994 7:43 PM 
'rlch@pegasus' 

'brianl@godzilla'; 'geert@godzilla'; 'hopper@godzj|la'; 'lisar@godzilla'; 'tbr@pegasus' 
Re: Euterpe PLL's 


Wampler wrote: 


> We can certainly hard- code every single component's power level, but 

this 

> means that the PLL gardswarts won't be able to track any subsequent 
changes 

> in the timing numbers as they are refined. Would it be more robust 
instead 

> to tighten the cycle time target for these gardswarts to get back the 

> guardband that would otherwise be lost by going from rcd=5 -> rcd=6 ? 
I 

> think it would be worth a try, since it doesn't involve much effort 

> (change one line in the Makefile and re-make) . I guess the major 
effort 

> would be re-doing the SPICE simulation of the final results, 

> although 

we 

> could perhaps just diff the power levels of all instances before and 
after, 

> and if they didn't change (or increased) we would know that we kept 
our 

> guardband . 
> 

> Further comments? 
> 

> - Kurt 


Rich replied: 


©It seems that as long as the timing would be checked by topt, leaving them as ©they 
currently are would be fine. As timing files change, topt should alert @us to any timing 
failures . 

@ 

@rich 

I think there are a couple of hazards here. 

1} We would be freezing an optimized version of the design without any 
way of reproducing it from first principles -- bootstrapping and 
burning the bridge behind us, so to speak. 

2) Topt won't warn us if our margin at rcd=5 starts to erode with updates 
to the timing libraries; we won't get a fatal error imtil the design 
fails at rcd=6. 


- Kurt 
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From: Geert Rosseel [geert@ambiorix] 
Sent: Tuesday, November 15, 1994 7:51 PM 
To: 'geert@goclzilla'; 'tbr@aphroclite' 

Cc: 'brianl@godzilla'; 'graham@godzjlla'; 'hopper@godzjlIa'; 'lisar@godzilla'; 'nch@godzilla'; 
'wampler@godzilla' 

Subject: Re: Euterpe PLL's 

Tim says : 

> how will topt correctly verify timing based on that 

> data, given we will actually be operating it with code 5? 

Thst is the hole in this strategy, we have no assurance that 
the PLL sofa will run at speed with resistor code 5. 

In the meeting thsi morning, we were assuming that rebuilding the 
PLL with different knob-settings was a big deal. However, Kurt does 
not believe so. The other idea is to run with rcd=6 and use a more 
agressive timing number. This too, of course does not assure that 
we will meet timing with red = 5. 

Geert 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Tim B. Robinson [tbr@aphrodite] 
Tuesday, November 15, 1994 11:34 PM 
'Guillermo A. Loyola' 

'dickson@bilbo'; 'euterpe@aphrodjte'; 'jeffm@rimulac'; 'lisar@rimutac'; Veena Malwankar" 
Re: shift overflow instructions 


Guillermo A. Loyola wrote (on Thu Nov 3) : 

I though Rich was still looking at possibly implementing those using the 1ms hardware. 
Otherwise I guess I'll have to change terp to be bug -compatible with the hardware 
(Bug because if the instruction does not do what it is supposed to it just shouldn't 
be there, but yea I know, checking for it to produce the exceptions is more atomes. 


Checking to cause the exception is trivial and we will add it. We also have the gates 
designed for the overflow check and if our latest routing experiments with the new knob 
setting leave empty space we could cut them in. I doubt that will happen. 


right?) . 


Tim 
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From: 


tbr 


To: 


Subject: 


Sent: 


Wednesday. November 16. 1994 12:04 AM 
'Mark Hofmann' 

Re: euterpe and cache drc tests 


Follow Up Flag: Follow up 
Flag Status: Red 

Mark Hofmann wrote (on Wed Nov 9): 
Tim B. Robinson writes: 
Better start some serious budget planning for 95. We are already way 


We have ordered an evaluation of a 90MHz dual spare module (eta 
4 weeks) and according to don there is expected to be an announcement 
from sun in the next week or so of lOOMHz modules. (The ones we have 
now are 50MHz I think). So there is a possibility of a significant 
speedup at modest cost. 

Okay. 

I don't have any idea what the '93 budget looks like. 

I think we should plan on needing more hardware, especially as we will have 
multiple chips in design, verification, and fracture/tapeout. 

1 would E^proach this by saying that we will be able to offset our 
hardware purchases by some amount as we reduce our sofhvare (CAD) costs 
by moving to our own home-grown tools. 

Should we meet to discuss this fiirdier? 

I tlaked to steve some and he'd going to do some analysis of 1994 
actual spending and relate that to headcount growth, so we can use 
that as a starting point for projection. 


over. 


Tim 
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From: Jay Tomlinson [woody@clemeter] 

Sent: Wednesday, November 16, 1994 12:08 AM 

To: Tim B. Robinson" 

Subject: forwarded message from Craig IHansen 


Tim B. Robinson wrote (on Tue Nov 1 5): 

As a result of this did you change anything? Assuming you didn't 
did your decision get incorporated into bob's document. 

To be honest I haven't even looked into it since I have been worlcing on he 
changes. The problem with it is that it adds more atoms to euterpe. 
I will talk to bob to make sure it is updated there. 

Jay 
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From: Mark Hofmann [hopper@tomato] 

Sent: Wednesday, November 16, 1994 12:20 AM 

To: Tim B. Robinson' 

Subject: Re: euterpe and cache drc tests 

Tim B. Robinson writes: 

I talked to steve some and he'd going to do some analysis of 1994 
actual spending and relate that to headcount growth, so we con use 
that as a starting point for projection. 

Okay. Let me know when we need to get together. 

-thanks, 
hopper 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Brian Lee [brianl@marathon] 

Wednesday, November 16, 1994 12:31 AM 

'Dave Van't Hof 

'Geert Rosseel'; 'Brian Lee' 

nb topt warnings 


Hi, 


In 


/n/auspex/s4l/euterpe-snapshot/euterpe/verilog/bsrc/nb/gards/nb-f inal. topt 
.log 

I find: 

(snip) 

Reading pin cap values from 
/n/auspex/s4 1 /eut erpe - snapshot / euterpe/proteus 
/exlax/ caps/ cap . lib 


Ignoring these nets: 

phi_b2p phi_a2p vref_Oph 

Warning! No vref_Oph pin capacitance data for ealporlSnf 8s3x4a Warning! No vref_Oph pin 
capacitance data for ealporl4nf 8s3x3a Warning" No vref_Oph pin capacitance data for 
eawwlvref 16s2x4a Warning! No vref_Oph pin capacitance data for ealporlSnf 8 s3x4a 

(lots more warnings about no pin capacitance data) 

However, in the cap. lib file, this data is present. Any ideas? 


(snip) 


Thanks, 


Brian L. 
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Subject: 


To: 


Sent: 


From: 


Cc: 


tbr 

Wednesday, November 16, 1994 12:32 AM 
'Wayne Freitas' 

'gap@echidna'; 'lisar@echidna'; 'iTiouss@echidna' 
AST N DA (the saga) 


Follow Up Flag: Follow up 
Flag Status: Red 

Wayne Freitas wrote (on Wed Nov 9): 
Tim; 

cc Grant and John; 

Tim, as you know I would like to use the AST box to help us in the 
bring-up and testing of Hestia by providing a standalone interfece that 
connected directly to Hermes. Currently the AST box has a 500MB 
internal bus but only supports a 200MB digital interface. When I spoke 
to the AST engineers a while back they were thinking about upgrading 
the interface to 500MB but not until 3rd Q of 95. T inquired about 
designing an interface for us that works around the 300MB range, and 
there response was positve, and what seemed of relative ease. Since 
then I have been trying to get a NDA signed, but have run into a 
multitude of problem with AST signing our NDA. So the question 1 have 
is, how much data constitutes signing an NDA, can we have them sign our 
NDA under some form of understanding on our part. I have outline two 
approaches as to what I view as necessary. 

1) (minimum) 

Data acquision and stimulus rate of 3S0MHz. (requires us to design interl^e circuit) 

I don't see why we would need an NDA just to request a generic 
interface at a specified data rate. What would be involved in the 
design of the interface circuits? If you have already identified 
components that would be compatible with our requirements perhaps it 
would be adequate to specify those components (or the specs of those 
components). That would then not involve any direct disclosure of our 
own interfaces 

2) (perfered) 

Vol, Vil, Voh, Vih, lol, lil, loh, lil, min-max elk duty cycle, elk to data set-up and hold time, 
Clock requirement ( divide by 2 for stimulus), pin capacitance, data overshoot 
and undershoot max, data and elk signals differential. 

As indicted before, I have always viewed the AST as a necessary 
bring-up tool to help exerise Calliope/Euterpe in a standalone mode 
for board and system level tests. We can still use the AST without 
the modification, but to connect to Hermes would require a level 
translator interface, and the PLL would have to be bypassed which 
defeats the purpose. Any help would be gready appreciated. 


Thanks, 


Wayne 
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>I had a telephone conversation with AST (AppHed Signal) and they 
>informed me that they could not execute an NDA with us and give us the 
>assurance that any AST employee would be bound by that agreement. It 
>seems that they do not execute NDA's with their people and as a result 
>none of their employees would be bound by our agreement - After 
>discussing this with Lois, 1 put AppHed Signal on an internal mission 
>to find a compromise, if any. 
> 

>So, what do they have a need to know? Can we proceed without an NDA? 
> 

>Grant 
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From: vant [vanthof@hestia] 

Sent: Wednesday, November 16, 1994 1:11 AM 

To: 'Brian Lee' 

Cc: 'vanthof@marathon'; 'geert@marathon'; 'brianl@marathon' 

Subject: Re: nb topt warnings 


Brian Lee writes: 


>ln 


>/n/auspex/ s41/euterpe- snapshot /euterpe/verilog/bsrc/nb/gards/nb-final.t 

>op 

t.log 

> 

>I find: 

> 

> (snip) 
> 

> Reading pin cap values from 
/n/auspex/s4l/euterpe-snapshot/euterpe/proteus 
>/exlax/caps/cap. lib 

> 

> (snip) 
> 

> Ignoring these nets: 

> phi_b2p phi_a2p vref_Oph 

>Warning! No vref_Oph pin capacitance data for ealporl5nf 8s3x4a 
>Warningl No vref_Oph pin capacitance data for ealporl4nf 8s3x3a 
>Warning! No vrefOph pin capacitance data for eawwlvref 16s2x4a 
>Warning! No vref_Oph pin capacitance data for ealporlSnf 8s3x4a 

> 

>(lots more warnings about no pin capacitance data) 
> 

>However, in the cap. lib file, this data is present. Any ideas? 
> 

>Thanks, 
> 

>- - 

> Brian L. 

> 

Hmmm. I don't know what's causing this. I'll look into it. A first pass glance seems to 
indicate that topt really things this pin is missing the cap data. So now I need to spend 
more time in the debugger. 

I'll keep you posted. 

Thanks, 
Dave 

Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, 
Inc . 

"What rolls down stairs, alone or in pairs, rolls over the neighbor's dog? 

What's great for a snack and fits on your back? It's log, log, log!" 
LOG from BLAMMO! (tm) All kids love Log! #incluce 
<std disclaim. h> 
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From: Lisa Robinson [lisar@aphrodite] 

Sent: Wednesday, Novennber 16. 1994 10:13 AM 

To: 'craig@aphrodlte'; 'lisar@aphrodite' 

Subject: Registered copy generated 


Copy created by: lisar 

Copy created at: Wed Nov 16 08:12:47 PST 1994 

Copy number: 282 

Copy registered to: Curtis Abbott 

Input file: 

/u/craig/documents/Terpsichore/Terpsichore .macps . gz . des 

Output file: /u/craig/documents/Terpsichore/Terpsichore .ps 

Printed to: rsh plotter Ipr -PCraig 

Recorded in file: /u/craig/documents/RegistrationLog 

[This message generated by /u/craig/bin/macpstops] 
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Sent: 

To: 

Cc: 


Subject: 


From: 


Curtis Abbott [abbott@taIlis] 

Wednesday, November 16, 1994 11:36 AM 

'Paul Poenisch' 

'Albert Matthews'; 'calliope@acteon'; 'Geert Rosseel'; 'Graham Y. Mostyn'; 'Lisa Robinson'; 
Tim B. Robinson' 
Metal changes in calliope 


Paul Poenisch wrote (on Wed Nov 16) : 
Graham and Geert, 

In reading through Curtis 's report on the QAM and NTSC receiver review meeting 
I noticed that at least three changes in the metallization layers of calliope 
to correct errors or improve it's performance were mentioned. Since I didn't 


I'm not the competent party to figure out all the tradeoffs here, but I believe the strong 
expectation is that getting the already taped out Calliope under some probes is going to 
reveal other design changes that we need to make, probably in both the digital and analog 
areas. 

Also, none of the envisioned or already designed metal changes are required to check out 
the chips. Building things costs dollars, but so does taping them out. Given all that, 
it seems unlikely that doing another tapeout now will result in an overall decrease in 
dollars and time spent . 


- Curtis 
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Subject: 


From: 
Sent: 
To: 
Cc: 


Tom Laidig [tonn@clio] 

Wednesday, November 16, 1 994 11 : 53 AM 

'Curtis Abbott' 

'paulp@acteon'; 'al@acteon'; 'calliope@acteon'; 'geert@acteon'; 'graham@acteon'i 
'lisar@acteon'; •tbr@acteon'; Thomas Laidig' 
Re: Metal changes in calliope 


Curtis Abbott writes: 


Paul Poenisch wrote (on Wed Nov 16) : 
Graham and Geert , 

In reading through Curtis 's report on the QAM and NTSC receiver review 
meeting I noticed that at least three changes in the metallization 
layers of calliope to correct errors or improve it ' s performance were 
mentioned. Since I didn't 


I'm not the competent party to figure out all the tradeoffs here, but I 
believe the strong expectation is that getting the already taped out 
Calliope under some probes is going to reveal other design changes that 
we need to make, probably in both the digital and analog areas. 
AlsO/ none of the envisioned or already designed metal changes are 
required to check out the chips. Building things costs dollars, but so 
does taping them out. Given all that, it seems unlikely that doing 
another tapeout now will result in an overall decrease in dollars and 
time spent. 

Yeah, I believe the proper tradeoff is to try to lump all our changes into one, I don't 
think any of the metal changes Curtis 's original message referred to have actually been 
made; perhaps the design changes have been made, but not a new placement and route. 

Also, the report from Photronics this morning (which arrived shortly after Paul sent his 
message) claims they fedex'ed the contact pedestal and metall masks yesterday. 


Tom L 


Exhibit C8 


Page 443 of 598 


From: tbr 

Sent: Wednesday. November 16. 1994 1:29 PM 

To: 'Paul Poonrsch' 

Cc: 'Curtis Abbott'; 'Albert Matthews'; 'calliope@acteon'; 'Geert Rosseel'; 'Graham Y. Mostyn'; 

'Lisa Robinson' 

Subject: Metal changes in calliope 

Follow Up Flag: Follow up 

Flag Status: Red 


Paul Poenisch wrote (on Wed Nov 16): 
Graham and Geert, 

In reading through Curtis's report on the QAM and NTSC receiver review meeting 
I noticed that at least three changes in the metallization layers of calliope 
to correct errors or improve if s performance were mentioned. Smce 1 didn't 
understand all of the discussion I suspect that there were more changes than 

three buried in the meeting. 

Since the Calliope metal reticles have not been made yet (Dupont still has not 
succeeded in making the contact pedestal layer), both Al and I agreed that 
we should make any improvements in the device we can and re-issue the tapes 
to the mask shops. It is a waste of the fab's time to make something we know 
isn't right to begin with. Note that when we are full up in production each 
wafer will cost us about $2000 to make and in pilot production it will be 
closer to $10000 each, plus $8000 to $10000 per reticle. This means that if 
we build 5 lots of each revision of a device to check it out (12 wafers per 
lot) it costs us about $700000 per turn. Cutting out one revision of Calliope 
will pay for itself very easily. 

Except that if our bum rate is $80000/day and doing another tapeout 

now for Calliope, delays us by 10 days to having working Euterpe it will cost us 

more overall (see below). 

I realize that there may be schedule impacts if we turn Calliope now but the 
cost of not turning it could be a lot higher in both schedule and $'s. If 
there are any improvements we can make in Calliope we should do it now before 
any reticles are made. 

We know of several corrections that need to be made. However, non of 
these are thought to be show stoppers as far as being able to 
demonstrate Hestia in a controlled envronment. They would be show 
stoppers for real deployment in trials. 

We have not been going through a re-tape out exercise for two reasons. 
First, (and graham should comment more on this), there is a very high 
likelyhood of having to make changes in the analog areas after we 
charaterize parts before they can be prodution ready anyway. So 
making a mask change now to correct well understood problems that we 
know how to work around is no help there. Second, and more 
importantly in my mind, doing this would delay Euterpe yet futher, and 
without a working euterpe so that we can run software on both chips 
together we will not be able to shake out system level problems that 
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will also likely be show stoppers if they occur. (Remember our entire 
verification effort to date is equivalent to a small fraction of I second of 
real time operation at IGHz.) 

So, while I agree that making fixes we already know about would be 
highly desirable if there were no schedule impact, I feel that in the overal 
plan, the critical path is getting the first limping version of 
Euterpe and Calliope together, and that this goal will be negatively 
impacted by another full blown verification and tapeout cycle on 
Calliope right now. 

Tim 
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Subject: 


From; 
Sent: 
To: 
Cc: 


Tim B. Robinson [tbr@aphrodite] 
Wednesday, November 16, 1994 1:29 PM 
'Paul Poenisch' 

'Curtis Abbott'; 'Albert Matthews'; 'calliope@acteon'; 'Geert Rosseel'; 'Graham Y. iVIostyn'; 

'Lisa Robinson' 

Metal changes in calliope 


Paul Poenisch wrote (on Wed Nov 16) : 
Graham and Geert, 

In reading through Curtis 's report on the QAM and NTSC receiver review meeting 
I noticed that at least three changes in the metallization layers of calliope 
to correct errors or improve it's performance were mentioned. Since I didn't 
understand all of the discussion I suspect that there were more changes than 
three buried in the meeting. 

Since the Calliope metal reticles have not been made yet (Dupont still has not 
succeeded in making the contact pedestal layer) , both Al and I agreed that 
we should make any improvements in the device we can and re- issue the tapes 
to the mask shops. It is a waste of the fab's time to make something we know 
isn't right to begin with. Note that when we are full up in production each 
wafer will cost us about $2 000 to make and in pilot production it will be 
closer to $10000 each, plus $8000 to $10000 per reticle. This means that if 
we build 5 lots of each revision of a device to check it out (12 wafers per 
lot) it costs us about $700000 per turn. Cutting out one revision of Calliope 
will pay for itself very easily. 

Except that if our burn rate is $80000/day and doing another tapeout now for Calliope, 
delays us by 10 days to having working Euterpe it will cost us more overall (see below) . 

I realize that there may be schedule impacts if we turn Calliope now but the 
cost of not turning it could be a lot higher in both schedule and $ ' s . 

If 

there are any improvements we can make in Calliope we should do it now before 
any reticles are made. 

We know of several corrections that need to be made. However, non of these are thought to 
be show stoppers as far as being able to demonstrate Hestia in a controlled envronment. 
They would be show stoppers for real deployment in trials. 

We have not been going through a re-tape out exercise for two reasons. 

First, (and graham should comment more on this), there is a very high likelyhood of having 
to make changes in the analog areas after we charaterize parts before they can be 
prodution ready anyway. So making a mask change now to correct well understood problems 
that we know how to work around is no help there. Second, auad more Importantly in my 
mind, doing this would delay Euterpe yet futher, and without a working euterpe so that we 
can run software on both chips together we will not be able to shake out system level 
problems that will also likely be show stoppers if they occur. (Remember our entire 
verification effort to date is equivalent to a small fraction of 1 second of real time 
operation at IGHz . ) 

So, while I agree that making fixes we already know about would be highly desirable if 
there were no schedule impact, I feel that in the overal plan, the critical path is 
getting the first limping version of Euterpe and Calliope together, and that this goal 
will be negatively impacted by another full blown verification and tapeout cycle on 
Calliope right now. 


Tim 
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From: tbr 

Sent: Wednesday. November 16, 1994 1:55 PM 

To: Tom Laidig' 

Cc: 'Curtis Abbott'; 'al@acteon'; 'calliope@acteon'; 'geert@acteon'; 'graham@acteon'; 

'lisar@acteon'; 'paulp@acteon'; Thomas Laidig* 

Subject: Re: IVIetal changes in calliope 

Follow Up Flag: Follow up 

Flag Status: Red 


Tom Laidig wrote (on Wed Nov 16): 
Curtis Abbott writes: 


jPauI Poenisch wrote (on Wed Nov 16): 
1 

I Graham and Geert, 

1 

I In reading through Curtis's report on the QAM and NTSC receiver review 
I meeting I noticed that at least three changes in the metallization 
j layers of calliope to correct errors or improve if s performance were 
I mentioned. Since I didn't 

i ..■ 
I 

ll'm not the competent party to figure out all the tradeoffs here, but 
jl believe the strong expectation is that getting the already taped out 
jCalliope under some probes is going to reveal other design changes 
jthat we need to make, probably in both the digital and analog areas. 
lAlso, none of the envisioned or already designed metal changes are 
[required to check out the chips. Building things costs dollars, but 
[so does taping them out. Given all that, it seems unlikely that doing 
{another tapeout now will result in an overall decrease in dollars and 
[time spent. 

Yeah, I believe the proper badeoff is to tiy to lump all our changes 
into one. I dont think any of the metal changes Curtis's original 
message referred to have actually been made; perhaps the design changes 
have been made, but not a new placement and route. 

The changes have been made and the affected blocks have been 
re-routed. We have not rerouted the top level. 

Also, the report from Photronics this morning (which arrived shortly 
after Paul sent his message) claims they fedex'ed the contact pedestal 
and metal 1 masks yesterday. 

Tim 
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From: Tim B. Robinson [tbr@aphrodite] 

Sent: Wednesday, November 16, 1994 1:55 PM 

To: Tom Laidig' 

Cc: 'Curtis Abbott'; 'al@acteon'; 'calliope@acteon'; 'geert@acteon'; 'graham @acteon'; 

'lisar@acteon'; 'paulp@acteon'; Thomas Laidig' 
Subject: Re: Metal changes in calliope 


Tom Laidig wrote (on Wed Nov 16) : 
Ciirtis Abbott writes: 


Paul Foenisch wrote (on Wed Nov 16) : 

Graham and Geert, 

In reading through Curtis ' s report on the QAM and NTSC receiver 

review 

I meeting I noticed that at least three changes in the metallization 
I layers of calliope to correct errors or improve it's performance 
were 

mentioned. Since I didn't 


I'm not the competent party to figure out all the tradeoffs here, but 
I believe the strong expectation is that getting the already taped out 
Calliope under some probes is going to reveal other design changes 
that we need to make, probably in both the digital and analog areas. 
Also, none of the envisioned or already designed metal changes are 
required to check out the chips. Building things costs dollars, but 
so does taping them out. Given all that, it seems unlikely that doing 
another tapeout now will result in an overall decrease in dollars and 
time spent. 

Yeah, I believe the proper tradeoff is to try to lump all our changes 
into one . I don ' t think any of the metal changes Curtis ' s original 
message referred to have actually been made? perhaps the design changes 
have been made, but not a new placement and route. 

The changes have been made and the affected blocks have been re-routed. We have not 
rerouted the top level. 

Also, the report from Photronics this morning (which arrived shortly 
after Paul sent his message) claims they fedex'ed the contact pedestal 
and metall masks yesterday. 

Tim 
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From: Graham Y. Mostyn [graham@polyhymnia] 

Sent: Wednesday, November 16, 1994 1:56 PM 

To: 'graham@acteon'; 'geert@acteon'; 'calliope@acteon'; 'pau!p@acteon' 

Cc: 'al@acteon'; 'abbott@acteon'; 'tbr@acteon'; 'lisar@acteon' 

Subject: Re: Metal changes in calliope 


I believe that we should use the existing tapes that have already been released to make 

our first Calliope wafers. 

My expectation is that while many of the analog sections will show reasonable 
functionality and be characterizable on first silicon, we may recjuire as many as two full 
mask changes (all layers) before a full-function Hestia can be produced in moderate 

volumes for trial deployment . 

The metal corrections so far identified pale into insignificance compared to the diffusion 
changes that will most likely be reejuired after this first evaluation; and none of the 
metal corrections preclude making the initial diagnosis . 

I therefore feel that we should focus CAD/design energies on Euterpe and Mnemo right now, 
and reserve these Calliope metal corrections, (along with probably a much more substantial 
set after first silicon 
evaluation) for the rev. 2 mask set. 

Graham . 

> From paulp®acteon Wed Nov 16 08:41:02 1994 

> From: paulpSacteon (Paul Poenisch) 

> Subject: Metal changes in calliope 

> To: graham@acteon (Graham Y. Mostyn), geertSacteon (Geert Rosseel) , 

> calliopeOacteon 

> Date: Wed, 16 Nov 94 8:40:51 PST 

> Cc: al®acteon (Albert Matthews), abbott®acteon (Curtis Abbott), 

> tbr@acteon (Tim B. Robinson), lisar®acteon (Lisa Robinson) 

> X-Mailer: ELM [version 2.3 PLll] 

> Content -Length: 134 6 
> 

> Graham and Geert, 

> 

> In reading through Curtis 's report on the QAM and NTSC receiver review 
meeting 

> I noticed that at least three changes in the metallization layers of 
calliope 

> to correct errors or improve it's performance were mentioned. Since I 
didn't 

> understand all of the discussion I suspect that there were more 

> changes 
than 

> three buried in the meeting. 

> Since the Calliope metal reticles have not been made yet (Dupont still 
has not 

> succeeded in making the contact pedestal layer) , both Al and I agreed 
that 

> we should make any improvements in the device we can and re- issue the 
tapes 

> to the mask shops. It is a waste of the fab's time to make something 

> we 
know 

> isn't right to begin with. Note that when we are full up in 

> production 
each 

> wafer will cost us about $2 000 to make and in pilot production it will 
be 

> closer to $10000 each, plus $8000 to $10000 per reticle. This means 
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that if 

> we build 5 lots of each revision of a device to check it out {12 

> wafers 
per 

> lot) it costs us about $700000 per turn. Cutting out one revision of 
Calliope 

> will pay for itself very easily. 

> 

> I realize that there may be schedule impacts if we turn Calliope now 

> but 
the 

> cost of not turning it could be a lot higher in both schedule and $ ' s . 
If 

> there are any improvements we can make in Calliope we should do it now 
before 

> any reticles are made. 
> 

> Paul. 
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From: Paul Poenisch [paulp@acteon] 

Sent: Wednesday, November 16, 1994 1:56 PM 

To: 'Tim B. Robinson' 

Cc: 'Graham Y. Mostyn'; 'Albert Matthews'; 'Curtis Abbott'; 'calliopetgacteon' 

Subject: Re: Metal changes in calliope 


Tim Robinson writes; 
> 

> This means that if 

> we build 5 lots of each revision of a device to check it out (12 
wafers per 

> lot) it costs us about $700000 per turn. Cutting out one revision 

> of 

Calliope 

> will pay for itself very easily. 
> 

> Except that if our burn rate is $800 0 0/day and doing another tapeout 

> now for Calliope, delays us by 10 days to having working Euterpe it 

> will 
cost us 

> more overall (see below) . 
> 

> I realize that there may be schedule impacts if we turn Calliope 

> now 
but the 

> cost of not turning it could be a lot higher in both schedule and 
$'s. If 

> there are any improvements we can make in Calliope we should do it 
now before 

> any reticles are made. 
> 

> We know of several corrections that need to be made. However, non of 

> these are thought to be show stoppers as far as being able to 

> demonstrate Hestia in a controlled envronment. They would be show 

> stoppers for real deployment in trials. 
> 

> We have not been going through a re -tape out exercise for two reasons. 

> First, (and graham should comment more on this) , there is a very high 

> likelyhood of having to make changes in the analog areas after we 

> charaterize parts before they can be prodution ready anyway. So 

> making a mask change now to correct well understood problems that we 

> know how to work around is no help there. Second, and more 

> importantly in my mind, doing this would delay Euterpe yet futher, and 

> without a working euterpe so that we can run software on both chips 

> together we will not be able to shake out system level problems that 

> will also likely be show stoppers if they occur. (Remember our entire 

> verification effort to date is equivalent to a small fraction of 1 
second of 

> real time operation at IGHz . ) 
> 

> So, while I agree that making fixes we already know about would be 

> highly desirable if there were no schedule impact, I feel that in the 
overal 

> plan, the critical path is getting the first limping version of 

> Euterpe and Calliope together, and that this goal will be negatively 

> impacted by another full blown verification and tapeout cycle on 

> Calliope right now. 
> 

> Tim 


I agree with most of your points. In talking to ras it became clear that I hadn't 
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expressed one of the major worries that Al and I have. We all 

under- 
stand that the first revision of Calliope had little chance of being usable in a final 
product, even before the problems we now know about were discovered, because of the fact 
that many of the circuits would need tweeks to be fully functional. We are concerened 
that if the changes that we now know are needed, that haven't been included in the current 
revision, also need tweeks then not putting them onto the revision now means that we will 
need another full design turn later to incorporate those tweeks. This would mean that not 
only would Calliope 1 have little chance of being commercially usable but we're also 
admitting that Calliope 2 will not be usable. If this is the case them were saving 10 
days on the schedule now at the cost of 2 months or more later (redesign, varif ication, 
fracture, mask generation, fab and test) . 
This 

dosen't soimd like a good trade-off. 
Paul. 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Kevin Peterson [khp@MicroUnity.com] 
Wednesday, November 16, 1994 4:25 PM 
'agc@MjcroUnity.com' 

'tbr@MicroUnity.com'; 'abbott@MicroUnity.com'; 'yam@MlcroUnity.com' 
Re: bit error rate testing 


> I would think that the smart card interface is more along the lines of 

> what we need, IR would require us to take the "symbol clock" and 

> multiply it to get a serial clock, calliope top-level indicates that 

> all SO output pins are connected to pads (I'm not sure about the 

> I0_DIRECTI0N field though) . This should give you 6 bits + elk. 

> If we were to increase the number of clock options then would this 

> suffice ? 

I counted only 6 output pins for SO including the I/O direction bit. 

We would need another bit /pin to provide a clock that's synthesized in software. We would 
also have to run the output interface at least 2x the symbol rate and every once in a 
while we would add an extra cycle between clock edges to maintain synchronization with the 
real symbol clock. 

Fur brought up the point that we might be able to use the ttl output pins on euterpe that 
are used to drive the LEDs . Apparently there are 
8 of them? Is there any validity to this approach? 

In response to tbr's question, a "full mux" data output is definitely outlined in the 
Toltec spec as part of their HSSI interface and it sure isn't defined. 


- -Kevin 


end 


Exhibit C8 


Page 453 of 598 


From: Richard Dickson [dickson@demeter] 
Sent: Wednesday, November 16, 1 994 5:1 3 PM 
To: 'tbr@demeter' 
Subject: mnemo pll in range detect 

tim, 

i've got rich m's in range detector logic first cut done, 
i still need to simulate it a bit more, i placed and routed it 
in a tmp directory in my euterpe directory tree, i'd like to 
check it in the mnemo directory tree, what are your thoughts on 
where it should go ie mnemo/verilog/src/ck ??? 

dickson 
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From: Derek Iverson [cloi@demeter] 

Sent: Wednesday, November 16, 1 994 5:19 PM 

To: 'guarlno@demeter'; 'gmo@demeter'; 'sandeep@demeter'; 'gregg@demeter'; 

'jeffm@demeter'; 'wayne@demeter' 
Cc: 'hestia@demeter' 

Subject: Software Bringup Meeting - November 16, 1 994 


Software Bringup Meeting 


November 16, 1994 

Next Meeting; November 2 3 at 10:00 am. 

Review of the bring-up section of the euterpe schedule. 
Review of CBI related issues. 

Attendees: jeffm, guarino, gmo, wayne, doi, sandeep, gregg 


Review of Action Items 


Item: Implement parallel port device drivers for sun and sgi . 
Who: sandeep, doi 

Status: on hold pending discussion of CBI at the Pandora Meeting (11/18) 

Item: Write up a plan for virtual devices and their interaction with 
gdb. 

Who : gmo 

Status: in progress 

Item: Build scripting/UI capabilities above gdb for regression tests. 
Who : doi 

Status: on hold until the the boot, gdb boot stub, and virtual devices 

are complete, (estimated start date of 12/23) 

Item: Implement remote gdb with the software simulator with microkernel 
Who : sandeep 
Status: done. 

Item: Get durations for items on the schedule for hestia function test 

Who : doi 

Status: in progress 

Here are the current estimates: 

Working Boot, Gdb boot stub. Virtual Devices 6 weeks 

write boot code 

write gdb boot stub 

write support for virtual devices 

bring-up on terp 
Bring-up boot on hardware simulator 2 weeks 

Bring-up gdb boot stub on hardware simulator 4 weeks 
Bring-up workstatation <-> hestia debug env. ?? weeks 
Bring-up boot and gdb boot stub on hestia ?? weeks 

Item: Identify our brinp-up tools and make sure we have plans for how 

we will debug them. 
Who : doi , et . al . 
Status: in progress 
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Item: Develop plan for testing real-time software before the analog 
parts of calliope work. 

Who : gregg 
Status: done 

Item: Determine which pins can be software controlled on each of the 
sun port. 

Who : doi 

Status: in progress (done by 11/18 [11/16]) 

Item: Create performance test plan 
Who: jeffm, guarino 
Status: no progress 

Item: Add Unix- like tests to software acceptance tests. 

who: guarino 

Status: no progress 

Item: CerbROM support from terp. 
Who : gmo , ssundeep 
Status: nearly done. 

New Action Items 


Item: Simulator needs to understand "reset' 
Who : grao 

Status: in progress (due 12/23) 

Item: Implement and bring-up boot, gdb boot stub, and virtual device 

support on the software simulator. 
Who : sandeep/grao 

Status: in progress (due 12/23) 


General Discussion 


None. Looking forward to the friday pandora meeting. 

Follow-up Data (This occured after the meeting but was included here) 


After the meeting, Loretta and Guillermo got together and came up with the following: 


Here are some back- of -the -envelope estimates Gmo and I came up with 
after today's meeting: 

We'll need to download programs: the Unix kernel is ~1 megabyte, the 
digital TV application (with the microkernel) is about 200 kilobytes. 
The smallest acceptance tests are 20 kilobytes. 

We'll need to support virtual devices: the load from the console 
should be negligible; we also need a virtual disk and virtual network. 
Real workstations get 3-4 megabytes per second from the disk and 1 
megabyte per second from the network. 

I/O buffering for realtime testing of TV application: 4 megsibytes of 
input and 4 megabytes of output. 

We'll need support not only for hardware bring-up itself, but for 
remote debugging to get the software working after we think the 
hardware is working. 
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Cost issues: we've discussed several scenarios for connecting to 
Hestia from a workstation,- here are additional hardware costs 
associated with each; 


serial port : dedicated host to poll the port 

parallel port: interface card for host 

dedicated ethernet: interface card for host 

full ethernet: interface for CBI 

gpib: interface card for host 


Guillermo adds: 


I wanted to add the fact that except maybe for the real-time code 
testing requirements, everything else mentioned is a requirement again 
for Pandora bringup. That is, I do envision bringin up OSF on Pandora 
using the virtual devices first, and then adding the PCI drivers. 
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From: Paul Berry [paulb@mercury] 

Sent: Wednesday, November 16, 1994 6:55 PM 

To: 'lisar@mercury'; 'abbott@mercury'; 'bobm@mercury'; 'tbr@mercury'; 'kgk@mercury' 
Subject: html vs Frame, screen vs paper, in doc displays 

Sometime fairly soon I think we should convene 
a review of the types and functions of documentation 
we want to produce and the audiences for whom we 

want to produce them. 

Specifically, I see a need to find the right mix of 
highly formatted page-oriented documents 

(such as FrameMaker produces) 
with user-formatted on-line documents and hypertext 
(such as those supported by html and displayed by Mosaic). 

There are major differences in the way these systems 
view the world. Frame is oriented to giving the author very 
precise control of the appearance of a document (or to 
switch from one very precise appearance to another). 

HTML gives all that control to the receiver rather than the 
sender of a document. HTML does not permit the author 
to specify a document's appearance, only its logical structure 
and connectivity. HTML deals with hierachical streams of text, 
but has no concept of such two-dimensional things as pages or tables. 
(Despite Mosaic's use of the term "home page", it isn't a page 
in the paper sense.) 

This is a major issue for us because our documentation has 
made heavy use of tables, but HTML has no concept of a grid of cells. 
(The best it can do is take a fixed-size snapshot of a table, which 
then remains undigested within the viewer's dynamically reformatted 
flow of text.) 

There are many very attractive things about using Mosaic to 
display HTML-based documents, but it will be quite 
complicated to move Frame documents to that environment. 
So we need to decide what we are trymg to achieve, and 
choose the tools for the aims... 
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From: vicki [vicki@charybdis] 

Sent: Wednesday, November 16, 1994 7:59 PM 

To: 'Geert Rosseel' 

Subject: Call your wife 


Software Bringup Meeting 

November 16, 1994 

Next Meeting: November 23 at 10:00 am. 

Review of the bring-up section of the euterpe schedule. 
Review of CBI related issues . 

Attendees: jeffm, guarino, gmo, wayne, doi, sandeep, gregg 
Review of Action Items 


Item: Implement parallel port device drivers for sun and sgi . 
Who: sandeep, doi 

Status: on hold pending discussion of CBI at the Pandora Meeting (11/18) 

Item: Write up a plan for virtual devices and their interaction with 
gdb. 

who : gmo 

Status: in progress 

Item: Build scripting/UI capabilities above gdb for regression tests. 
Who : doi 

Status: on hold until the the boot, gdb, boot stub, and virtual devices 

are complete, (estimated start date of 12/23) 

Item: Implement remote gdb with the software simulator with microkernel 
Who : sandeep 
Status : done . 

Item: Get durations for items on the schedule for hestia function test 
Who: doi 

Status: in progress 

Here are the current estimates: 

Working Boot, Gdb boot stub, virtual Devices 6 weeks 

write boot code 

write gdb boot stub 

write support for virtual devices 

bring-up on terp 
Bring -up boot on hardware simulator 2 weeks 

Bring-up gdb boot stub on hardware simulator 4 weeks 
Bring-up workstatation <-> hestia debug env. ?? weeks 
Bring-up boot and gdb boot stub on hestia ?? weeks 


Item: Identify our brinp-up tools and make sure we have plans for how 

we will debug them. 
Who: doi, et.al. 
Status: in progress 

Item: Develop plan for testing real- time software before the analog 
parts of calliope work. 
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Who : gregg 
Status : done 

Item: Determine which pins can be software controlled on each of the 

sun port. 
Who : doi 

Status: in progress (done by 11/18 [11/16]) 

Item: Create performance test plan 
Who: jeffm, guarino 
Status: no progress 

Item: Add Unix- like tests to software acceptance tests. 

Who : guarino 

Status: no progress 

Item: CerbROM support from terp. 
Who : gmo , sandeep 
Status: nearly done. 

New Action Items 


Item: Simulator needs to understand "reset' 
Who : gmo 

Status: in progress (due 12/2 3) 

Item: Implement and bring-up boot, gdb boot stub, and virtual device 

support on the software simulator. 
Who : sandeep/gmo 

Status: in progress (due 12/23) 


General Discussion 


None. Looking forward to the friday pandora meeting. 

Follow-up Data {This occured after the meeting but was included here) 


After the meeting, Loretta and Guillermo got together and came up with the following: 

Here are some back-of- the- envelope estimates Gmo and I came up with 
after today's meeting: 

We'll need to download programs: the Unix kernel is -1 megabyte, the 
digital TV application (with the microkernel) is eUaout 200 kilobytes. 
The smallest acceptance tests are 20 kilobytes. 

We'll need to support virtual devices: the load from the console 
should be negligible; we also need a virtual disk and virtual network. 
Real workstations get 3-4 megsJaytes per second from the disk and 1 
megabyte per second from the network. 

I/O buffering for realtime testing of TV application: 4 megabytes of 
input and 4 megabytes of output. 

We'll need support not only for hardware bring-up itself, but for 
remote debugging to get the software working after we think the 
hardware is working. 

Cost issues: we've discussed several scenarios for connecting to 
Hestia from a workstation; here are additional hardware costs 
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associated with each: 


serial port: dedicated host to poll the port 

parallel port: interface card for host 

dedicated ethernet: interface card for host 

full ethernet: interface for CBI 

gpib: interface card for host 


Guillermo adds: 


I wanted to add the fact that except maybe for the real-time code 
testing requirements, everything else mentioned is a requirement again 
for Pandora bringup. That is, I do envision bringin up OSF on Pandora 
using the virtual devices first, and then adding the PCI drivers. 
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From: tbr 

Sent: Wednesday. November 16, 1994 9:31 PM 

To: 'Paul Poenisch' 

Cc: 'Curtis Abbott'; 'Albert Matthews'; 'calliope@acteon'; 'Graham Y. Mostyn' 

Subject: Re; Metal changes In calliope 


Follow Up Flag: Follow up 
Flag Status: Red 


Paul Poenisch wrote (on Wed Nov 16): 

I agree with most of your points. In talking to ras it became clear tliat I 
hadn't expressed one of the major worries that Al and I have. We all under- 
stand that the first revision of Calliope had little chance of being usable 
in a final product, even before the problems we now know about were discovered, 
because of the lact that many of the circuits would need tweeks to be fully 
fiinctional. We are concerened that If the changes that we now know are needed, 
that haven't been included in the current revision, also need tweeks then not 
putting them onto the revision now means that we will need another full 
design turn later to incorporate those tweeks, This would mean that not 
only would Calliope 1 have little chance of being commercially usable but 
we're also admitting that Calliope 2 will not be usable. If this is the case 
them were saving 10 days on the schedule now at the cost of 2 months or more 
later (redesign, varification, fracture, mask generation, fab and test). This 
dosent sound like a good trade-off. 

I think there is relatively little chance of such a second order 
effect provided we devote a fiill verification effort to the revised 
tapeout. The errors we are discussing here are not the result of bugs 
undetedected in verification before the first tapeout, but rather 
errors in our understanding of the required functionality. le we 
built what we intended, but it turned out it was not what was actually 
needed as our understanding of the software matured. There will 
continue to be exposures of this kind till we have at least a first 
limping chipset (ie Calliope/Euterpe pair) which will allow realistic 
software to run in real time. 

Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Tim B. Robinson [tbr@aphrodite] 
Wednesday, November 16, 1994 9:31 PM 
'Paul Poenisch' 

'Curtis Abbott'; 'Albert Matthews'; 'calliope@acteon'; 'Graham Y. Mostyn' 
Re: Metal changes in calliope 


Paul Poenisch wrote (on Wed Nov 16) : 

I agree with most of your points. In talking to ras it became clear that I 
hadn't expressed one of the major worries that Al and I have. We all 
\mder- 

stand that the first revision of Calliope had little chance of being usable 
in a final product, even before the problems we now know about were discovered, 
because of the fact that many of the circuits would need tweeks to be fully 
functional. We are concerened that if the changes that we now know are needed, 
that haven't been included in the current revision, also need tweeks then not 
putting them onto the revision now means that we will need another full 

design turn later to incorporate those tweeks. This would mean that not 
only would Calliope 1 have little chance of being commercially usable but 
we're also admitting that Calliope 2 will not be usable, if this is the case 
them were saving 10 days on the schedule now at the cost of 2 months or more 
later (redesign, varif ication, fracture, mask generation, fab and test) . This 
dosen't sound like a good trade-off. 

I think there is relatively little chance of such a second order effect provided we devote 
a full verification effort to the revised tape out . The errors we are discussing here are 
not the result of bugs undetedected in verification before the first tapeout, but rather 
errors in our understanding of the required functionality. le we built what we intended, 
but it turned out it was not what was actually needed as our understanding of the software 
matured. There will continue to be exposures of this kind till we have at least a first 
limping chipset (ie Calliope /Euterpe pair) which will allow realistic software to run in 
real time. 


Tim 
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From: 
Sent: 
To: 

Subject: 


Arya Behzad [arya@hepatu] 

Wednesday, November 16, 1994 9:52 PM 

'hestia@hepatu' 

Re: Netlist meeting minutes 


> 1) Transmitter component change and prt change to be completed 

> (arya/ras) by 11/15. 


Done. 


> 


> 2) Sense lines from RO power supply; add connection traces with jumper 

> to Euterpe or Calliope, with initial jumper set to Euterpe, 

> (arya /woody) 
Done. 

> 7) Define topside castings ( arya/ t be) 
In progress 


> 10) Vias to be placed tieing chip substrate to ground 

> (arya/grahara) 

Based on several methods of estimating the via inductance, the inductance of a 32mil long, 
10 mil diameter via is between 0.22nh to 0.38nh. Based on this we would need between 
about 15 to 3 0 vias for the substrate current (assuming the via inductance is the only 
major inductance involved and, a required lOraV ripple allowed on substrate voltage, 2 00mA 
peak spikes, and 300ps dt . ) I will be looking at this issue a little more in detail, but I 
think the results would indicate that about 30 or 40 vias would be more than enough. 


> 


> 


> 


> 


> 


> 


> 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Tim B. Robinson [tbr@aphroclite] 
Wednesday, November 16, 1994 9:66 PM 
'Mark Semmelnneyer' 
'geert@aphrodite' 

euterpe/verilog/bsrc/rgxmit rgxmit.V 


Mark Semmelmeyer wrote (on Wed Nov 16) : 

Update of /p/cvsroot/euterpe/verilog/bsrc/rgjonit 

In directory medusa: /N/auspex/root/s24/mws/euterpe/verilog/bsrc/rgxmit 

Modified Files: 

rgxmit .V 
Log Message: 

r gxmit/ rgxmit .V: Evicted PC way- station to ife. Saved 1485 atoms. 
More , more ! 


Tim 
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From: tbr 

Sent: Wednesday, November 16, 1994 10:41 PM 

To: 'Richard Dickson' 

Subject: mnemo pll in range detect 

Follow Up Flag: Follow up 
Flag Status: Red 


Richard Dickson wrote (on Wed Nov 16): 
tim, 

i've got rich m's in range detector logic first cut done, 
i still need to simulate it a bit more, i placed and routed it 

in a tmp directory in my euterpe directory tree, i'd like to 
check it in the mnemo directory tree, what are your thoughts on 
where it should go ie mnemo/verilog/src/ck ??? 

See the last message to rich. I think it should go in 
proteus/verilog/src/pl 

with the rest of the PLL stuff, since these PLLs are supposed to be 
generic, even though we never seem to use the same one twice! 

Please have module names starting pl_ to follow th convention. 

Tim 
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From: 


tbr 


To: 


Subject: 


Sent: 


Cc: 


Wednesday, November 16, 1994 11:17 PM 

'Arya Behzad' 

'hestia@hepatu' 

Re: Netlist meeting minutes 


Follow up Flag: Follow up 
Flag Status: Red 

Aiya Behzad wrote (on Wed Nov 16): 

> 1) Transmitter component change and prt change to be completed 

> (arya/ras) by 11/15. 
Done, 


> 2) Sense lines from RO power supply; add connection traces 

> with jumper to Euterpe or Calliope, with initial jumper set to 

> Euterpe, (arya/woody) 
Done. 

> 7) Define topside castings (arya/tbe) 
In progress 


> 10) Vias to be placed tieing chip substrate to ground 

> (aiya/graham) 

Based on several methods of estimating the via inductance, the inductance 
of a 32mil long, 10 mil diameter via is between 0.22nh to 0.38nh. Based 
on this we would need between about 15 to 30 vias for the substrate 
current (assuming the via inductance is the only major inductance involved 
and, a required lOmV ripple allowed on substrate voltage, 200mA peak spikes, 
and 300ps dt.) 

I will be looking at this issue a little more in detail, but I think 

the results would indicate that about 30 or 40 vias would be more than 

enough. 


What is the DC current capacity of the vias? 40 would give us about 
l^A per via which feels very comfcMtable to me, and in fact is likely 
to be considerably more than we get at the PSU end where we have 
double the current. Has anyone calculated this? 


> 


> 
> 


> 


> 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Tim B. Robinson [tbr@aphrodite] 

Wednesday, Novennber 16, 1994 11:17 PM 

'Arya Behzad' 

'hestia@hepatu' 

Re: Netlist meeting minutes 


Arya Behzad wrote (on Wed Nov 16) : 


> 1} Transmitter component change and prt change to be completed 

> (arya/ras) by 11/15. 


Done. 


> 2} Sense lines from RO power supply; add connection traces 

> with jumper to Euterpe or Calliope, with initial jumper set to 

> Euterpe, (arya/woody) 
Done . 

> 7) Define topside castings (arya/tbe) 
In progress 


> 10) Vias to be placed tieing chip substrate to ground 

> < arya /graham) 

Based on several methods of estimating the via inductance, the inductance 
of a 32mil long, 10 mil diameter via is between 0.22nh to 0.38nh. 
Based 

on this we would need between about 15 to 3 0 vias for the substrate 
current (assuming the via inductance is the only major inductance involved 
and, a required lOmV ripple allowed on substrate voltage, 200mA peak spikes, 
and 3 00ps dt . ) 

I will be looking at this issue a little more in detail, but I think 
the results would indicate that about 3 0 or 40 vias would be more than 
enough . 


What is the DC current capacity of the vias? 4 0 would give us about 1/2A per via which 
feels very comfortable to me, and in fact is likely to be considerably more than we get at 
the PSU end where we have double the current. Has anyone calculated this? 


Tim 
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From: Eld red Felias [efelias@poseidon] 

Sent: Thursday, November 17, 1994 9:35 AM 

To: 'B. P. Wong' 

Cc: 'Geert Rosseel' 

Subject: Output from "at' job (fwd) 


BP, 


Here is the Ivs report on MB (on ISS) . It seems to be complaining on the block that 
Orlando worked on (MBXDEC) . Question: Was MBXDEC ran on Dracula or ISS? Was it ISS Ivs 
clean? Is MBXDEC heirarchically correct? I haven't really looked over the results yet 
but I suspect there's probably a subcell that was flattened within another cell. 

Eldred 

. whetherPorwarded message : 

>From rootogodzilla Thu Nov 17 15:11:48 1994 
>Date: Thu, 17 Nov 1994 15:11:46 -0800 
>FroTn: rootogodzilla (vant) 

>Message-ld: <199411172311 . PAA25123®godzilla.raicrounity . com> 
>To: ef elias@godzilla 

>Subject: Output from "at" job 

> 

>Your "at" job "6084" produced the following output: 

> 

> 

>Working cell: mb 

>Using flow: /u/chip/technology/mobimos/iss//mobilvsl_p611 . vc 
>Translation table for Cif To Stream: 
/u/chip/tools/lib/stream/mobiraosl . tbl 
> 

>Current working directory: /usr/local/etc/dracjobs/isslvs Current 

> Layout : mb 

>rm: cannot remove . ' or . . ' 
>rm : cannot remove " . * or " . . ' 
> 

>LTLPATH: /a/iss 
>ISSPATH: /a/iss 
>ISS_SYSTYPE : SUN4 
>ISS_LSERVER: hestia 
> 

>/a/iss/SUN4_verichk/vc_engine 

>/**************************************************** 

> * * 

> * IIIIIII SSSSSS SSSSSS * 

> * ISS * 

> * ISS * 

> * I SSSSS SSSSS * 

> * ISS * 

> * ISS * 

> * IIIIIII SSSSSS SSSSSS * 

> * * 

>/******************************************************* 

> 

>cdl2iss -pl 

>Parsing /n/auspex/s9/ef elias/vlsir/euterpe/mb . sp 
>Creating schematic. iss.tmp 
>Creating cell.equiv 

> 

>UNWIRE Hierarchical Netlist Wire Remover - Version BETA 1.7 3/10/94 
>Copyright (C) Integrated Silicon Systems 1991-1993. All rights reserved. 
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>Creating composite LVS explode and flatten lists 

> 

^Starting date: Thu Nov 17 09:43:15 PST 1994 
> 

>/u/chip/tools/bin/cif les -c tnb -v 

/n/auBpex/s9/efelias/vlsir/euterpe/vlsi.boo -o /dev/null -A datain.dat -h 
cell.equiv -I -n 15793.txt -e 1 -Y -G BBOX -x 
/u/chip/tools/lib/streara/mobimosl . tbl >>& mb.log 
>Running vericheck 

> gdsin: 5.1.2 6/22/94 

> gdsout: 5.1.8 6/6/94 

> here: 2.4.2 7/21/94 

> Ish: 2.4.15 8/18/94 

> vc_engine: 2.4.122 8/30/94 

> vp: 2.4.17 7/11/94 
>VeriCheck is done. 

> 

>VeriCheck (R) Hierarchical Design Verification, BETA 2.4.1 

> (C) Copyright 1990, 1991, 1992, 1993, 1994. 

> Integrated Silicon Systems, Inc. All rights reserved. 

> This product contains confidential information and trade secrets of 

> Integrated Silicon Systems, Inc. Any use or disclosure, except as 

> authorized in writing by Integrated Silicon Systems, Inc., is 

> prohibited. Copyright is claimed in this product as an unpxjblished 

> work, and the copyright notice does not imply publication. 
> 

>Printing individual version numbers . . . 
> 

> vericheck: 2.4.9 8/24/94 
> 

>Check following files for results: 

> Error File = "MB.cmperr" 

> Summary File = "MB.cmpsum" 
> 

>herc [options] <Netlist> <Runset> 

> -e<file> : Redirect error messages to error file 

> -n# : Set net size limit when printing connections 

> -b <block> : Set block 

> -r <root> : Set root cell 

> -s <file> : Redirect log messages to summary file 

> -z : Print nets with zero connections 
> 

>Check following files for results: 

> Error File = "MB.ercerr" 

> Summary File = "MB.ercsum" 
> 

>VeriCheck is done. 

>* Compare summary * 

> CAINVBV3 != MBINVBV3B 

> MBXDKC2 != MBXDKC2 

> CAINVBV3 != MBINVBV3A 

> MBCELL8X64 != MBCELL8X64 

> CAINVBV3 i= MBINVBV3B (level 10) 

> MBXDEC2 != MBXDEC2 (level 10) 

> CAINVBV3 1= MBINVBV3A (level 10) 

> MBCELL8X64 1= MBCELL8X64 (level 7) 

> MBLBLDVR == MBLBLDVR 

> MBMCELL2X2 == MBMCELL2X2 

> BGBBCSTM == BGBBCSTM 

> CA0R3WP == CA0R3WP 

> CAOR2WP == CAOR2WP 

> MBGSA == MBGSA 

> CAORIWP == CAORIWP 

> MBNAND2BV3 == MBNAND2BV3 

> CAINVBV4 == CAINVBV4T 
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> CAINVBV5 == CAINVBV5 

> CAXDRV == CAXDRV 

> MBLOCSA == MBLOCSA 

> BEIiliYBUTT == BELLYBUTT 

> CAINVBV4 == CAINVBV4 

> MBLSEL MBLSEL 

> MBYDECl == MBYDECl 

> MBSBITIO == MB8BITI0 

> MBSBITIO == MB8BITI0_R 

> MBCEIiL2X32 mm NBCELL2X32 

> CAWRPRE8 CAWRPRE8 

> CAWRPRE4 == CAWRPRE4 

> MBDINBUF == MBDINBUF 

> CAWRPRE4 == MBYPRE4 

> CAWRPRE2 == MBYPRE2 

> MBYDECl 6 == MBYDECl 6 

> MBCELL2X64 == MBCELL2X64 

> MBXPREDEC == MBXPREDEC 

> MBYPREDEC == MBYPREDEC 

> MBBITIO == MBBITIO 

> MBLBLDVR == MBLBLDVR (level 10) 

> MBMCELL2X2 == MBMCELL2X2 (level 10) 

> BGBBCSTM == BGBBCSTM (level 10) 

> CA0R3WP == CA0R3WP (level 10) 

> CA0R2WP == CA0R2WP (level 10) 

> MBGSA == MBGSA (level 10) 

> CAORIWP == CAORIWP (level 10) 

> MBNAND2BV3 == MBNAND2BV3 (level 10) 

> CAINVBV4 == CAINVBV4T (level 10) 

> CAINVBV5 == CAINVBV5 (level 10) 

> CAXDRV == CAXDRV (level 10) 

> MBLOCSA == MBLOCSA (level 10) 

> BELLYBUTT BELLYBUTT (level 10) 

> CAINVBV4 == CAINVBV4 (level 10) 

> MBLSEL == MBLSEL (level 9) 

> MBYDECl == MBYDECl (level 9) 

> MBSBITIO == MBSBITIO (level 9) 

> MBSBITIO == MB8BITI0_R (level 9) 

> MBCELL2X32 == MBCELL2X32 (level 9) 

> CAWRPRE8 == CAWRPRE8 (level 9) 

> CAWRPRE4 CAWRPRE4 (level 9) 

> MBDINBUF == MBDINBUF (level 9) 

> CAWRPRE4 == MBYPRE4 (level 9) 

> CAWRPRE2 == MBYPRE2 (level 9) 

> MBYDEC16 == MBYDEC16 (level 8) 

> MBCELL2X64 == MBCELL2X64 (level 8) 

> MBXPREDEC == MBXPREDEC (level 8) 

> MBYPREDEC MBYPREDEC (level 8} 

> MBBITIO == MBBITIO (level 7) 


>****************************#************** 
>******************************************* 
>** ** 

>** THERE ARE OPENS IN YOUR CIRCUIT ** 
>** PLEASE LOOK IN MB. err ** 

>** ** 

^s,* ****************************************** 


>mv MB. sum MB. err MB.cmpsum MB.craperr MB.net MB.ercsum MB.ercerr MB. tree 

schematic . iss cell , equiv edtext . dat compare 

>mv: MB.ercsum: Cannot access: No such file or directory 

>mv: MB.ercerr: Cannot access: No such file or directory cp -rp compare/ 

>/n/auspex/s9/ef elias/vlsir/euterpe/mb . compare 

>cp: compare// .matched/MBLBLDVR: No such file or directory 

>cp: compare// .matched/BGBBCSTM: No such file or directory 
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compare// .matched/CA0R3WP: No such file or directory 
compare// .matched/CAOR2WP: No such file or directory 
compare// .matched/MBGSA: No such file or directory 
compare// .mat ched/CAORlWP: No such file or directory 
compare// .matched/MBNAND2BV3 : No such file or directory 
compare// .matched/CAINVBV4T: No such file or directory 
compare// .mat ched/CAlNVBV5 : No such file or directory 
compare// .matched /CAXDRV: No such file or directory 
compare// .matched/CAINVBV4 : No such file or directory 
compare// .mat ched/MBLSEL: No such file or directory 
compare// .mat ched/MBYDECl : No such file or directory 
compare// .mat ched/MB8BITI0: No such file or directory 
compare// .matched /MB 8BITI0_R: No such file or directory 
compare// .mat ched/MBCELL2X3 2 : No such file or directory 
compare// .matched/CAWRPRES : No such file or directory 
compare// .matched/ CAWRPRE4 : No such file or directory 
compare// .matched/MBDiNBUF: No such file or directory 
compare// .mat ched/MBYPRE4 : No such file or directory 
compare// .matched/MBYPRE2 : No such file or directory 
compare// .matched/MBYDECie : No such file or directory 
compare// .mat ched/MBCELL2X64 : No such file or directory 
compare// .matched/MBXPREDEC: No such file or directory 
compare// .matched/MBYPREDEC: No such file or directory 
compare// .mat ched/MBBITIO: No such file or directory cat mb.log » 
>/n/auspex/s9/ef elias/vlsir/euterpe/mb. compare/mb. Ivslog 
> 

>ISS LVS completed 
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From: Patricia Mayer [pmayer@hera] 

Sent: Thursday. November 17, 1994 11:01 AM 

To: 'aryai^hepatu'; 'tbr@aphrodite' 

Cc: 'hestia@hepatu' 

Subject: Re: Netlist meeting minutes 


> From tbr@aphrodite Wed Nov 16 21:14:35 1994 

> Date: Wed, 16 Nov 1994 21:16:38 -0800 

> From: tbr®aphrodite (Tim B. Robinson) 

> To: aryaOhepatu (Arya Behzad) 

> Cc : hestiaOhepatu 

> Subject: Re: Netlist meeting minutes 

> Content -Length: 1297 


> Arya Behzad wrote (on Wed Nov 16) : 
> 

> > 1) Transmitter component change and prt change to be completed 

> > (arya/ras) by 11/15. 

> Done . 
> 

> > 

> > 2) Sense lines from RO power supply; add connection traces 

> > with jumper to Euterpe or Calliope, with initial jumper set to 

> > Euterpe, (arya/ woody) 

> Done . 
> 

> > 7) Define topside castings (arya/tbe) 

> In progress 

> > 

> > 

> > 

> > 10) vias to be placed tieing chip substrate to ground 

> > (arya /graham) 

> Based on several methods of estimating the via inductance, the 
inductance 

> of a 32niil long, 10 mil diameter via is between 0.22nh to 0.38nh. 
Based 

> on this we would need between about 15 to 3 0 vias for the substrate 

> current (assuming the via inductance is the only major inductance 
involved 

> and, a required lOmV ripple allowed on substrate voltage, 2 00mA 

> peak 
spikes, 

> and 3 oops dt.) 

> I will be looking at this issue a little more in detail, but I think 

> the results would indicate that about 30 or 40 vias would be more 
than 

> enough . 

> > 
> 

> What is the DC current capacity of the vias? 4 0 would give us about 

> 1/2A per via which feels very comfortable to me, and in fact is likely 

> to be considerably more than we get at the PSU end where we have 

> double the current. Has euiyone calculated this? 
> 

Jean- Yves calculated this last night and I added a 12X12 grid of 10 mil drill vias. 
Done 

> Tim 
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From: Jean-Yves Michel [yves@thalia] 

Sent: Thursday, November 1 7, 1 994 1 1 : 1 5 AM 

To: 'tbr@aphrodlte' 

Cc: 'hestia@thalia' 

Subject: Re: Netttst meeting minutes 


Tim Robinson vnrote: 

> > 

> > 10) Vias to be placed tieing chip substrate to ground 

> > ( a rya/ graham) 

> Based on several methods of estimating the via inductance, the 
inductance 

> of a 32mil long, 10 mil diameter via is between 0.22nh to 0.38nh. 
Based 

> on this we would need between about 15 to 3 0 vias for the substrate 

> current (assuming the via inductance is the only major inductance 
involved 

> and, a required lOmV ripple allowed on substrate voltage, 200mA 

> peak 
spikes, 

> and 3 oops dt . ) 

> I will be looking at this issue a little more in detail, but I think 

> the results would indicate that about 30 or 4 0 vias would be more 
than 

> enough . 

> > 
> 

> what is the DC current capacity of the vias? 4 0 would give us about 

> 1/2A per via which feels very comfortable to me, and in fact is likely 

> to be considerably more than we get at the PSU end where we have 

> double the current. Has anyone calculated this? 
> 

> Tim 


Arya's calculation relates to the vias from Calliope /Euterpe substrate (back of the die) 
to ground. These carry only ac current induced by the collectors and the drain of the 
transistors. These vias are under the spacer planes outside the tab frame area. 

Regarding the vias carrying the main ground current, they connect the back of the space 
transformer to the board ground plane. They are immediately underneath the space 
transformer. I used the following calculation for the number of via: 

For Euterpe, we have 25A DC current with 3A spikes, 300ps wide. In order to keep the 
ripple below SOraV, l = V * dt/dl = 0.050 * 150 e-12 / 3 = 2.5pH With 0.25nH per via, we 
need 100 vias. 

On the other side Euterpe has 113 VDDE pad on the TAB, therefore 113 vias to the power 
plane. 

Therefore, I settled for 144 (12X12) minimum size vias with 42mils space. 
This cover 

an area of sibout 11.7 mm on a side, slightly more than the space transformer area. 

The same number of via was used for Calliope, which has a lower current but needs a 
qpiieter supply for the analog section. 

DC wise, we should not have any problem with that many vias. 
Jean- Yves 
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From: Jay Tomlinson [woody@demeter] 
Sent: Thursday, November 1 7, 1 994 11 : 1 8 AM 
To: 'tbr@demeter* 
Subject: event daemon 

Tim, 

yesterday scott came by and we discussed his proposed change to the event 
daemon. Mainly, he would like to use the HC queues instead of the SP queue. I 
think this is actually simpler and is likely to cost less euterpe atoms. 

The only added complexity (given today's nb protocol) is that he will have to 
manuf a store response to nb. The sol'n to this will likely cause me to make 
store responses at the time the packet is sent to the channel. This may be able 
to reduce the size of the write response fifo. I hate to get into this when we 
may end up getting rid of store response to nb anyway. 

The other main question that I had, is what address do we pick. Dp we eat into 
the 32-bit hermes address? Do we use the upper channel address bits, which will 
only work for this implementation? 

Just something to think about. 

Jay 
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From: Lisa Robinson [[jsar@nosferatul 

Sent: Thursday, November 17, 1994 12:10 PM 

To: 'Tim B. Robinson'; 'agc@nosfieratu'; 'khp@nosferatu'; Vo@nosferatu' 
Subject: so device register connections 


Tim B. Robinson wrote (on Thu Nov 17): 


I don't know if Tom Vo sent you a copy of his reply, but it 
seems that you are right and tfiere was an error in top-level 
hookup that snuck thru verification. Probably cause we didnt 
verify the fimction of the spare pins. 

At the toplevel we didn't verify the function of ANY of the spare 

pins. My ommisson. 

At the system level (terp + calliope) we did verify the functionality 
of sisparedatal abm, aisparedatal abm, sosparedata2_abm and 
sosparedatal_abm but not sosparel_abm or sospare2_abm. 

LisaR. 


> Alan Cony wrote .... 

>> 

> >Forwarded message: 

> »From khp@MicroUnity.com Wed Nov 16 17:59:34 1994 

> >Date: Wed, 16 Nov 94 17:59:26 -0800 

> >From: khp@MicroUnity.com (Kevir Peterson) 

> >Message-Id: <941 1 170159.AA17459@spirot.microunity.com> 

> >To: agc@MicroUnity.com 

> >Subject: so device register connections 

> > 

> > 

> >rve been poking around calliope. V in an attempt to update my 

> >calliope,h and I found what appears to be a wrong connection. As I 

> >understand it, the pi device register bit PI_LINE_SENSE uses one of 

> >the so spare pins, sospare2_abm. This is consistent with the verilog 

> >below. However, I couldnt find the connection of the other so device 

> >register spare bit to sosparel abm. It appears from the verilog below 

> >that sosparel_abm is connected to so_data[SO SPARE 1] instead of 

> >so_de vice_register[SO_SPARE 1 ] . 

> > 

> >What do you think? 

>> 

> >from calliope.V (lines 1869-1888): 

> >#ifhdef EXCLUDE jjadsjl 
>> pads_tl pads ti ( 

> > vrr 1 7 , vff sw 1 7 , bufset_abm, 

> > t2cfg0, t2cfg 1, t2cfg2, t2cfg3, t2cfg4, t2cfg5, t2cfg6, 

> > t2cfg0_abm, t2cfg l_abm, t2cfg2_abm, t2cfg3_abm, t2cfg4_abm, t2cfg5_abra, t2cfg6_abm, 

> > DB(ai_device_register,AI_AULOOP), auloop_abm, 

> > D(ir_pwr), irpwr_abm, 

> > DB(so_data, SO_SPARE 1 ), sospare l_ahm, 
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> > DB(pi_device_register,PI_LINE_SENSE), sospare2_abm, 

> > ring_abm, D(pi_ring^m), 

> > D(off_hookJn), D(off_hook_out), callerid_abm, offhook__abm, 

> > D(irjbit), iriii_abin, irout_abni, D(ii_bit), 

> > DB(so_data,SO_CLK), DB(so_data,SO_RESET), DB(so_data,SO_DIRECTION), 

> > DB(so_data, SO_IO__DIRECTION), DB(so_data,SO_D ATA_OU'i:), 

> > DB(si_data,SI_DATA_IN), srdir abm, srclk abm, srrst abm , srio_abm, 

> > DB(si data,SI_CARD_DETECT), srdetect_abm, 

> > DB(so__data, SO_SPARE_DATA I ), sosparedata 1 _abm, 

> > DB(so_data, SO_SPARE_DATA2), sosparedata2_abm 

>> ); 

> >#endif EXCLUDE_pads_tl 

> > 

> > 
>> 
> 

> 1 think you're right ; sosparel_abm is mis-wired to the data register instead of the device 

> register . The current connection has sospareI_abm doing the same thing as the so clock . 
> 

>tvo 
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From: Lisa Robinson [lisar@nosferatu] 

Sent: Thursday, November 17, 1994 12:14 PM 

To: 'Tim B. Robinson'; 'agc@nosferatu'; 'khp@nosferatu'; Vo@nosferatu' 

Cc: 'calliope@nosferatu' 

Subject: so device register connections 


Tim B. Robinson wrote (on Thu Nov 17) : 


I don't know if Tom Vo sent you a copy of his reply, but it 
seems that you are right and there was an error in top-level 
hookup that snuck thru verification. Probably cause we didn't 
verify the function of the spare pins. 

At the toplevel we didn't verify the function of ANY of the spare pins. My oraniisson. 

At the system level {terp + calliope) we did verify the functionality of sisparedatal_abm, 
aisparedatal_abm, sosparedata2_eibm and sosparedatal_abm but not sosparel_abm or sospare2 
_abm. 

Lisa R. 


> Alan Corry wrote .... 

> > 

> >Forwarded message : 

> >>From khp®MicroUnity . com Wed Nov 16 17:59:34 1994 

> >Date: Wed, 16 Nov 94 17:59:26 -0800 

> >From: khp®MicroUnity . com (Kevin Peterson) 

> >Message-Id: <9411170159 . AA17459@spirot .microunity . cora> 

> >To: agcdMicroUnity.coro 

> ^-Subject: so device register connections 

> > 

> > 

> >I've been poking around calliope. V in an attempt to update my 

> >calliope.h and I found what appears to be a wrong connection. As I 

> >understand it, the pi device register bit PI_LINE_SENSE uses one of 

> >the BO spare pins, sospare2_abm. This is consistent with the verilog 

> >below. However, l couldn't find the connection of the other so device 

> >register spare bit to sosparel_abm. It appears from the verilog below 

> >that sosparel_abm is connected to so_data [S0_SPARE1] instead of 

> >so_device_register [SO_SPAREl] . 

> > 

> >What do you think? 

> > 

> >from calliope. V (lines 1869-1888) : 

> >#ifndef EXCLUDE_pads_tl 

> > pads_tl pads_tl { 

> > vrrl7 t vffswl7, bufBet_abra, 

> > t2cfg0, t2cfgl, t2cfg2, t2cfg3, t2cfg4, t2cfg5, t2cfg6, 

> > t2cfg0_abm, t2cfgl_abm, t2cfg2_abm, t2cfg3_abra, 
t2cfg4_abra, t2cfg5_abm, t2cfg6_abm, 

> > DB (ai__device_register , AI_AULOOP) , auloop_abm, 

> > D(ir_jpwr), irpwr_abm, 

> > DB(so_data, S0_SPARE1) , sosparel_abm, 

> > DB (pi_device_register, PI_LINE_SENSE) , sospare2_abra, 

> > ring_abm, D (pi_ring_in) , 

> > D (of f_hook_in) , D (of f _hook_out ) , callerid_abm, 
o f f hook_abm , 

> > D(ir_bit), irin_abm, irout_abm, D(ii_bit), 

> > DB ( so_data , SO_CLK) , DB (so_data, SO_RESET) , 
DB(so_data,SO_DIRECTION) , 
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srio_abm. 


) 1 

>#endif EXCLXJDE_pads_tl 


DB ( so_dat a , S0_IO_DIRECTI0N ) , DB ( so_da ta , S0_DATA_OUT ) , 
DB (si_data, SI_DATA_IN) , srdir abra, srclk_abm, srrst__abm 

DB ( si_data , SI_CARD_DETECT) , srdetect_abm , 
DB ( so_data / S0_SPARE_DATA1 ) , sospar edatal_abm , 
DB(so_data, S0_SPARE_DATA2) , sosparedata2_abm 


> > 

> > 


> I think you're right : sosparel_abTii is mis-wired to the data register instead of the 
device 

> register . The current connection has sosparel_abm doing the same thing as the so 
clock . 


> tvo 
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From: 


tbr 


Subject: 
Follow Up Flag: 
Rag Status: 


Sent: 


To: 


Cc: 


Thursday, November 17, 1994 3:06 PM 

'Jay Tomlinson' 

'craig' 

event daemon 
Follow up 
Red 


Jay Tomlinson wrote 


(onThu Nov 17): 


Tim, 


yesterday scott came by and we discussed his proposed change to the event 
daemon. Mainly, he would like to use the HC queues instead of the SP queue. I 
think this is actually simpler and is likely to cost less euterpe atoms. 

I tend to agree that we had again been overlooking the negative 
consequences of using the slow Q. However, it does require an 
architectural change to define distinct daemon addreses for each channel. 

The only added complexity (given today's nb protocol) is that he will have to 
manuf. a store response to nb. The sol'n to this will likely cause me to make 
store responses at the time the packet is sent to the channel. This may be able 
to reduce the size of the write response fifo. I hate to get into this when we 
may end up getting rid of store response to nb anyway. 

The other main question that I had, is what address do we pick. Do we eat into 
the 32-bit hermes address? Do we use the upper channel address bits, which will 
only work for this implementation? 

Just something to think about. 

We need an address per hemes channel and we should allow for the 
possibility of implementations with more channels. However, 
we ought to keep them out of the 32 bit range. I thmk this will meen 
adding another term to the finont end decoder in NB to drop them into 
the right Q. You will also have to mark them someway (probably the 
address is enough), so that you know what they are when they get to 
he. 


Tim 


Exhibit C8 


Page 480 of 598 


Subject: 


Sent: 

To: 

Cc: 


From: 


Tim B. Robinson [tbr@aphrocllte] 
Thursday, November 17, 1994 3:06 PM 
'Jay Tomlinson' 
'craig@aphrodite' 
event daemon 


Jay Tomlinson wrote (on Thu Nov 17) : 


Tim, 


yesterday scott came by and we discussed his proposed change to the event 
daemon. Mainly, he would like to use the HC queues instead of the SP queue. I 
think this is actually simpler and is likely to cost less euterpe atoms. 

I tend to agree that we had again been overlooking the negative consequences of using the 
slow Q. However, it does require an architectural change to define distinct daemon 
addreses for each channel. 

The only added complexity (given today's hb protocol) is that he will have to 
manuf . a store response to nb. The sol'n to this will likely cause me to make 
store responses at the time the packet is sent to the channel. This may be able 
to reduce the size of the write response fifo. I hate to get into this when we 
may end up getting rid of store response to nb anyway. 

The other main question that I had, is what address do we pick. Do we eat into 
the 32 -bit hermes address? Do we use the upper channel address bits, which will 
only work for this implementation? 

Just something to think about . 

We need an address per hemes channel and we should allow for the possibility of 
implementations with more channels. However, we ought to keep them out of the 32 bit 
range. I think this will meen adding another term to the front end decoder in NB to drop 
them into the right Q. You will also have to mark them someway (probably the address is 
enough) , so that you know what they are when they get to he . 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Jay Tomlinson [woocfy@clytemnestra] 
Thursday, November 17, 1994 3:22 PM 
'Tim B. Robinson' 
'craig@aphrodite' 
event daemon 


Tim B. Robinson wrote {on Thu Nov 17) : 


Jay Tomlinson wrote (on Thu Nov 17) : 


Tim, 


yesterday scott came by and we discussed his proposed change to the event 
daemon. Mainly, he would like to use the HC queues instead of the SP queue. I 
think this is actually simpler and is likely to cost less euterpe atoms. 

I tend to agree that we had again been overlooking the negative 
consequences of using the slow Q. However, it does require an 
architectural change to define distinct daemon addreses for each channel. 

The only added complexity (given today's nb protocol) is that he will have to 
manuf . a store response to nb. The sol'n to this will likely cause rae to make 
store responses at the time the packet is sent to the channel. This may be able 
to reduce the size of the write response fifo. I hate to get into this when we 
may end up getting rid of store response to nb anyway. 

The other main question that I had, is what address do we pick. Do we eat into 
the 32 -bit hermes address? Do we use the upper channel address bits, which will 
only work for this implementation? 

Just something to think about. 

We need an address per hemes channel and we should allow for the 

possibility of implementations with more channels. However, 

we ought to keep them out of the 32 bit range. I think this will meen 

adding another term to the front end decoder in NB to drop them into 

the right Q. You will also have to mark them someway (probably the 

address is enough) , so that you know what they are when they get to 

he. 


This means using a unique space to identify this. We could use one space for all channels. 
Scott didn't seem to care much for this idea when I suggested it to him, but I don't think 
he was totally against it. He was more in favor of using the 32 -bit range. I agree with 
you that we shouldn't prevent ourselves from having a bunch of memory out there. 

As far as your orig plan of using the SP queue. Was this viewed as an architecture change 
(long term) or strickly a micro -architecture deviation from the arch (this implementation 
only) ? 

If you have some time today, could you talk to Craig about this, I don't want this to drag 
out . 


Tim 


jay 
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From: Mark Hofmann [hopper@rhodan3 
Sent: Thursday, November 17,1 994 4: 1 8 PM 
To: Tim B. Robinson' 
Subject: Re: forwarded message from Alan Corry 

Tim B. Robinson writes: 

How do we check the licence status for this one? Is it possible we 
Just have some stuck licences? 

Tim 

1 think it might be about time we a few more licenses. I was unable to get 
a license this afternoon when I asked for one. Another designer, and overlap 
of debug on euterpe and mnemo in the next few weeks will probably cause this 
to happen again. 

I just installed a new command "towlic" to find users of undertow. 

When rich needed a license earlier this week we checked all 6 licenses 
were in use by 6 different people. They all appeared recent and 
legitimate. 

-hopper 
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From: 


tbr 


Cc: 


Sent: 


To: 


Subject: 


Thursday, November 17, 1994 11:14 PM 
'Lisa Robinson' 

'agc@nosferatu'; 'khp@nosferatu'; 'vo@nosferatu' 
so device register connections 


Follow Up Flag: Follow up 
Flag Status: Red 

Lisa Robinson wrote (on Thu Nov 17): 

Tim B. Robinson wrote (on Thu Nov 17): 

I don't know if Tom Vo sent you a copy of his reply, but it 
seems that you are right and there was an error in top-level 
hookup that snuck thru verification. Probably cause we didn't 
verify the function of the spare pins. 

At the toplevel we didn't verify the function of ANY of the spare 
pins. My ommisson. 

At the system level (terp + calliope) we did verify the functionality 
ofsisparedatal abm, aisparedatal abm, sosparedata2_abm and 
sosparedatal abm but not sosparel_abm or sospare2_abm. 

Please be sure we have this logged in the gnats database. 


Tim 
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From: vant [vanthof@hestia] 

Sent: Thursday, November 17, 1994 11:41 PM 

To: 'Lisa Robinson' 

Cc: 'Dave Van't Hof ; 'Mark Hofmann'; 'Tim B. Robinson'; 'Lisa Robinson'; 'Geert Rosseel'; 'Tom Vo' 
Subject: Re: Ikos simulation 

Lisa Robinson writes: 

> 

> 

>One week ago Ikos installed the software associated with their 
>hardware simulator, nsim, prior to the installation of the hardware 
>scheduled for delivery during the week of November 28. This software 
>includes a complete emulation environment capable of running exactly 
>the same "netlist" as the hardware accelerator which allows us to 
>verify our new cell libraries, netlist compiles, stimulus compiles 
>etc. prior to installation of the hardware. 
> 

>Today we successfully ran the main euterpe datapath in this environment. 

> 

>YEAH! 
> 

>Lisa R. 

> 

Congratulations! 
Dave 

Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, Inc. 
255 Caspian Way, Sunnyvale, OA (408) 734-8100 X276 #inc1ude <std_disclaim.h> 
Don't blame me, I didn't vote for him! 
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From: tbr 

Sent: Thursday, November 1 7. 1 994 1 1 :45 PM 

To: 'hopper* 

Subject: forwarded message from Alan Corry 

Follow Up Flag: Follow up 
Flag Status: Red 

How do we check the licence status for this one? Is it possible we 
just have some stuck licences? 

Tim 


Start of forwarded message 

Return-Path: <agc@ares> 

Received: from ares.microunity.com by gaea.microunity.com (4.1/musel3) 

id AA26757; Thu, 17 Nov 94 14:19:46 PST 
Received: from localhost by ares.microunity.com (8.6.4/muse-sw.2) 

idOAA18157;Thu, 17 Nov 1994 14:20:14 -0800 
Message-Id: < 1 994 1 1 1 72220 .OA A 1 8 1 57@ares.microunity.com> 
X-Mailer: ELM [version 2.3 PLll] 
From: agc@ares (Alan Corry) 
To: tbr@ares (Tim B. Robinson) 
Cc: hopper@ares (Mark Hofmann) 
Subject: undertow 

Date: Thu, 17 Nov 94 14:20:13 GMT 

I think it might be about time we a few more Hcenses. I was unable to get 
a license this afternoon when I asked for one. Another designer, and overlap 
of debug on euterpe and mnemo in the next few weeks will probably cause this 
to happen again. 


End of forwarded message 
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From: 
Sent: 
To: 

Subject: 


tbr 

Friday, November 18. 1994 12:48 AM 
'Marie Hofmann' 

Re: forwarded message from Alan Corry 


Follow Up Flag: Follow up 
Flag Status: Red 

Mark Hofniann wrote (on Thu Nov 17): 

Tim 6. Robinson writes: 

How do we check the licence status for this one? Is it possible we 
just have some stuck licraces? 


I think it might be about time we a few more licenses. I was unable to get 
a license this afternoon when I asked for one. Another designer, and overlap 
of debug on euterpe and mnemo in the next few weeks will probably cause this 
to happen again. 

I just installed a new command "towlic" to find users of undertow. 

When rich needed a license earlier this week we checked all 6 licenses 
were in use by 6 different people. They all appeared recent and 
legitimate. 


Tim 


Thanks. 


Tim 
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From: Eric Murray [ericm@MicroUnity.com] 
Sent: Friday, November 18, 1994 10:01 AM 
To: 'sysadm@MicroUnity.com' 
Subject: disk usage report 


For directories over 100 megs: 

user's info: 


brianl 

1563 

hopper 


chip 

1033 

fwo 

971 

geert 

958 

dickson 

948 

craig 

880 

tbr 

868 

jsw 

684 

rozen 

577 

vanthof 

559 

gmo 

557 

vijay 


h 

488 

sandeep 

486 

brendan 

479 

rocky 

448 

qua 

/I 'JO 

brian 

417 

wampler 

376 

fur 

333 

doi 

315 

khp 

288 

age 

283 

ken 

271 

hchu 

270 

torn 

269 

tbe 

265 

wingard 

261 

veena 

260 

warren 

250 

jef!m 

247 

ras 

236 

fiing 

220 

peter 

206 

rich 

204 

bill 

203 

solo 

202 

iimura 

200 

gregg 

192 

haim 

191 

lisar 

189 

bpw 

188 

mws 

184 

hessam 

183 

al 

181 

biliz 

174 

Vandyke 

173 

ericm 

172 
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woody 

167 

cox 

161 

albers 

154 

guarino 

153 

lisa 

151 

randy 

142 

karzes 

141 

chuck 

139 

fambro 

136 

jeff 

135 

dane 

132 

jeny 

130 

octtools 

130 

tomho 

128 

mikew 

127 

yves 

120 

ong 

115 

paulb 

112 

hayes 

110 

larryk 

103 


packages info: 


chip-euterpe-buil 2049 

calliope 

1579 

news 

1379 

euterpe-verify 

1011 

soft-src 

948 

chip-archive 

881 

orchis snap 

811 

chip-proteus 

800 

caliiope-disk2 

730 

losf-build 

693 

cadence 

636 

ptolemy 

628 

archives 

608 

sun 

571 

osf 

564 

cadence.hp 

552 

calliope l-fractur 487 

chip-calliope 

484 

chip-terpsichore 475 

soil 

475 

sgi 

377 

xllr5_kenj326 329 

castor-retry 

325 

bosf-build 

323 

chip-archive-terp 318 

calliope-overflow 297 

bigtmp 

283 

mips-4.52 

282 

chip-archive-mnem 259 

Xllr4 

228 

bsd 

222 

cadence_doc 

221 

synopsys 

216 

cadence doc 9402 215 

budtool_db 

190 

budtool 

186 

Motif 

177 
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mechanica 

164 

sgi5 

152 

ikos 

150 

ucberl 

147 

vlsi.v8r4_2 

145 

proe tmp 

138 

ftp 

134 

khoros 

134 

proe_13.0 

134 

calliope-verify 

132 

lib 

129 

iimura.be 

128 

gnu 

125 

bsd43 

115 

frame-4.0.3 

115 

svr4 

114 

Xllr5 

111 

chip-mdunit 

105 

motif 1.2 

101 


machine user megs package megs total megs max capacity % used 

auspex 20856 19427 40283 59499 67% 

rama 3738 2380 6119 9428 64% 

rhea 223 1602 1826 2484 73% 

gaea 5 1775 1780 1780 100% 

cronus 630 2521 3152 6208 50% 


auspex rama rhea gaea cronus: 
25452 27705 


53160 


79399 


66% 
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From: Jay Tomlinson [woody @luckboy] 
Sent: Friday, November 18, 1994 10:04 AM 
To: 'lisar@luckboy' 
Cc: 'tbr@luckboy' 
Subject: cmos array verification 

Lisa, 

Do you have any plans for verificiation of read/write of the CMOS arrays in 
euterpe? I bring this up because by inspection I noticed that the gtlb write 
mable is not asserted for enough cycles. I think the models need to be updated 
to make this detectable in some way (maybe writing x's). 

jay 
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From: Lisa Robinson [lisar@nosferatu] 
Sent: Friday, November 18, 1994 10:21 AM 
To: 'Jay Tomlinson' 
Cc: 'tbr@nosferatu' 
Subject: cmos array verification 

Jay Tomlinson wrote (on Fri Nov 18): 
Lisa, 

Do you have any plans for verificiation of read/write of the CMOS arrays in 
euterpe? I bring this up because by inspection I noticed that the gtlb write 
enable is not asserted for enough cycles. I think the models need to be updated 
to make this detectable in some way (maybe writing x's). 

jay 


We have models in place for the icache, dcache, itag and dtag which 
will be picked up in the next simulator build but not yet for the gtlb 
and register file. 


Lisa R. 
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From: 
Sent: 
To: 

Subject: 


Bob Morgan [bobm@mercury] 
Friday, November 18, 1994 12:29 PM 
'euterpe@mercury' 
Microarchitecture release 1 .5 


Hi, 

I sent something out about this yesterday afternoon, but I don't think it ever showed up. 
I released version 1.5 of the microarchitecture document. The changes are listed in the 
change file ( changes. mlf) . 

They include updates to the opcode tables, and information on valid operations in each 
address space. Interleaved Hermes channels, exception priority, and the new format of the 
instruction cache tag protection field. 

As always, you can print out a copy using the Makefile, type "gmake book". Or, I can 
print out a bound hardcopy for whoever weuits one. 

Any comments or suggestions welcome. 

Thanks , 

Bob 
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From: 


tbr 


Sent: 

To: 

Cc: 


Friday, November 18, 1994 12:29 PM 

'Bob Morgan' 

•|isar@mercury' 

Re: Cerb reg. 0-2 as in TSA 4/14/94 


Subject: 


Follow Up Flag: Follow up 
Flag Status: Red 

Bob Morgan wrote (on Fri Nov 18): 

The microarchitecture and TSA agree in the structure 

of Cerberus registers 1-2, but not in the values. 

The ones in the TSA refer to Calliope. 

Thanks, 

Bob 

According to my copy, page 176, there are definedvalues for Euterpe, 
not Calliope. 


Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Kevin Peterson [khp@MicroUnity.com] 
Friday, Novennber 18, 1994 1:24 PM 
'Scott Furman' 

•Gregg Kellogg'; 'brendan@MlcroUnity.com'; 'khp@MicroUnity.com' 
Re: (Fwd) Realtime Software Test Plan 


A while ago Scott, you were talking about using the QPSK receiver to get bits in real- 
time. Shouldn't we be pursuing this option as well? 

Yes, it requires a working calliope (or a barely working calliope) but the QPSK 
functionality in calliope is probably the lowest risk interface (since it's all digital) 
and it's likely to work before anything else. We can definitely use the AST box to 

synthesize a qpsk stream on the fly. 

Verifying the output is obviously much more difficult. It sure would be nice if had a 
high speed generic digital interface (8 bits + clock) on euterpe that we could use to 
output raw data. (This came up in the context of BER testing of the QAM receiver too) . I 
wonder if it • s too late to ask for this? Here too we could use the AST box to capture the 
data, up to the limits of our deep memory (128 MBytes) . There are too many blocks in the 
path between the video decoder and the NTSC output so we really do need to use memory to 
precisely verify full frame buffers (which should be time stamped so we can compare them 
to simulated output frame buffers) . 


- Kevin 


- Kevin 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Scott Furman [fur@quetzalcoatl] 
Friday, November 18, 1994 1:64 PM 
'Gregg Kellogg' 

'Scott Furman'; 'brendan@MicroUnity.com'; 'khp@MlcroUnity.com' 
Re: (Fwd) Realtime Software Test Plan 


Gregg Kellogg writes: 
> have more like 7.5 Meg {in an 8 Meg machine) to use as buffer space. 

We need greater than 2 Meg for the four decompression frame buffers, so it's more like 5 
Meg available as buffer space. 


> I'm certainly open to other schemes if they're feasible. 


I'm not trying to shoot you down. I'm just reminding you of what you already know: 
debugging of real-time code on Euterpe is going to be difficult and probably entail a good 
deal of cruf t . A lot of these problems could have been prevented if we had thought ahead 
to ensure a high-speed digital interface on Euterpe. 


Scott 
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Sent: 

To: 

Cc: 


Subject: 


From: 


Scott Furman [fur@quetzalcoatl] 
Friday, November 18, 1994 3:40 PM 
'Kevin Peterson' 

'gregg@quetzalcoatr; 'brendan@quetzalcoatr 
Re: (Fwd) Realtime Software Test Plan 


Kevin Peterson writes: 
> 

> Verifying the output is obviously much more difficult. It sure would > be nice if had 
a high speed generic digital interface (8 bits + clock) > on euterpe that we could use to 
output raw data. (This came up in the > context of BER testing of the QAM receiver too) . 
I wonder if it's too > late to ask for this? Here too we could use the AST box to 
capture > the data, up to the limits of our deep memory (128 MBytes) . There are > too 
many blocks in the path between the video decoder and the NTSC > output so we really do 
need to use memory to precisely verify full > frame buffers (which should be time stamped 
so we can compare them to > simulated output frame buffers) . 


The shame of it is that the l/O's to handle such an interface are already on Euterpe in 
the form of the LED display and keyboard interface. These lines provide a total of 12 
digital outputs and 4 digital inputs, though not all of these pins are generic TTL. Early 
on, I suggested that Euterpe be responsible for scanning the LED display and keyboard so 
that these I/O's could be more generic. After all, the scan rate for these devices was 
going to be at most a few hundred hertz, which wouldn't put any real load on Euterpe. 
Unfortunately, these lines are all in the Cerberus clock domain, which renders them 
difficult and slow to use. 


-Scott 
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From: paulb (Paul Berry) 

Sent: Friday, November 1 8, 1 994 8:54 PM 

To: 'Ibr* 

Subject: Pandora notes from today's meeting 

All the notes are m ~paulb/cvs/pandora/doc/notes. 
There's a book called pandoraNotes.book, and then 
individual files with names such as 941 11 8.doc 
(which is today's, and the last now m the book). 

It contains several known questionable items (they show 
with change bars in red on screen), not to mention the 
errors I don't know about... 
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From: tbr 

Sent: Saturday, November 19, 1994 12:39 AM 

To: 'doi' 
Subject: vltree 
Follow Up Flag: Follow up 
Flag Status: Red 


I think it could use some tuning! I have been running it against the 
euterpe top level and it's still going after 51 minutes! 

Tim 
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From: doi (Derek Iverson) 

Sent: Saturday, November 1 9, 1 994 1 2:59 AM 

To: 'tbr (Tim B. Robinson)' 

Subject: vltree 

Tim B. Robinson writes: 

> 

> I think it could use some tuning! 1 have been running it against the 

> euterpe top level and it's still going after 5 1 minutes! 

I haven't done anything with it since we talked about it last weekend. 
Is it able to let you get things done or are you stuck? 

Clearly the right thing to do is to simply have smaller designs. This 
way the tool wouldn't take as long to run. :-) 

How about checking with Lisa about where this should fit in my priority list 
so I have an idea about how much time I should spend with it? 

doi 
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From: tbr 

Sent: Saturday, November 1 9, 1 994 1 :06 AM 

To: 'doi (Derek Iverson)* 

Subject: vltree 
Follow Up Flag: Follow up 
Flag Status: Red 


Derek Iverson wrote (on Fri Nov 18): 

Tim B. Robinson writes; 
> 

> I think it could use some tuning! I have been running it against the 

> euterpe top level and it's still going after 51 minutes! 

1 haven't done anything with it since we talked about it last weekend. 
Is it able to let you get things done or are you stuck? 

Not stuck. In fact I think I was feeding it rather more than I 
needed. I think giving it the cache is what was causing it to grind 
to a halt. I took that out (since it was not supoposed to be in 

there) and it seems to have completed in around 10 mins. 

Clearly the right thing to do is to simply have smaller designs. This 
way the tool wouldn't take as long to run. :-) 

How about checking with Lisa about where this should fit in my priority list 
so I have an idea about how much time I should spend with it? 

I'm OK for now. The vendor of the half baked verilog translator has 
promised to add library searching (eventually). 


Tim 
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From: 


tbr 


To: 


Subject: 


Sent: 


Sunday. November 20, 1994 2:05 AM 
'dickson' 

floating inputs in cerb 


Follow Up Flag: Follow up 
Flag Status: Red 


When I run euterpe throught he IKOS compile I see a whole load of 
floating inputs in cerberus. Any idea what this could be? Here's a 
sample: 

warning [2001032.6]: pm \cerb\u03\u00\ul 130\ul000\DUMMYlNST4.DATA is floating 
warning [2001032,6]: pm\ceFb\uO3\uO0\ull30\ul0OO\DUMMYINST4.DATA is floating 
warning [2001032,6]: pin \cerb\u03\uOO\ul 130\ulOOO\DUMMYTNST4.DATA is floating 
warning [2001032,6]: pin \cerb\u03\uOO\ul 130\ul000\DUMMYINST4.DATA is floating 
warning [2001032,6]: pin \cerb\u03\u00\ul 130\ul000\DUMMYrNST4.DATA is floating 
warning [2001032,6]: pin \cerb\u03\uOO\ul 130\ul000\DUMMYINST4.DATA is floating 
warning [2001032,6]: pin \cerb\u04\ul0O0\ulOO0\ull30\ulOOO\DUMMYnsrST17.DATA is floating 
warning [2001032,6]: pin\cerb\u04\ul000\ul000\uU30\ul0OO\DUMMYINST17.DATA is floating 
warning [2001032,6]: pin\cert)\u04\ul000\ul000\ull30\ulOOO\DUMMYINST17.DATA is floating 
warning [2001032,6]: pin \cerb\u04\ul000\ul000\ul 130\ulOOO\DUMMYINST17.DATA is floating 
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From: Eric Murray [ericm@MicroUnity.com] 
Sent: Sunday, November 20, 1994 10:01 AM 
To: 'sysadm@MicroUnity.com' 
Subject: disk usage report 

For directories over 100 megs: 
user's info: 


hopper 

1023 

chip 

1018 

diclcson 

972 

geert 

957 

tor 

943 

craig 

881 

jsw 

684 

rozen 

577 

vanthof 

559 

gmo 

553 

hchu 

548 

vijay 

513 

h 

491 

sandeep 

486 

brendan 

479 

rocky 

452 

qua 

433 

brian 

417 

wampler 

377 

veena 

338 

fur 

336 

jeffin 

1 1 A 

doi 

289 

age 

282 

ken 

271 

torn 

269 

tbe 

245 

solo 

239 

ras 

235 

fiing 

zzv 

iimura 

208 

peter 

206 

rich 

204 

bill 

203 

brianl 

197 

gregg 

191 

haim 

191 

lisar 

189 

bpw 

186 

mws 

185 

hessam 

183 

al 

181 

two 

178 

ericm 

172 

Vandyke 

172 

billz 

161 

guarino 

160 

cox 

160 

albers 

158 


Exhibit C8 


Page 503 of 598 


woody 

155 

Hsa 

147 

randy 

142 

karzes 

141 

chuck 

139 

dane 

138 

fambro 

138 

jeff 

135 

jerry 

131 

octtools 

130 

mikew 

129 

tomho 

129 

yves 

121 

ong 

115 

paulb 

114 

hayes 

111 


packages info: 
chip-euterpe-buil 2114 
calliope 1579 
euterpe- verify 1011 
calliope-disk2 730 
losf-build 697 


cadence 

636 

archives 

608 

sun 

571 

osf 

564 

cadence.hp 

552 

soft 

520 

calliope 1 -fractur 487 

chip-calliope 

484 

chip-terpsicho 

re 475 

sgi 

377 

budtool 

376 

news 

340 

bosf-build 

323 

ch ip-arch ive-terp 3 1 8 

calliope-overflow 297 

mips-4,52 

282 

bigtmp 

274 

jeffin.old 

273 

chip-arch ive-mnem 259 

Xllr4 

228 

bsd 

222 

cadence_doc 

221 

synopsys 

216 

cadence doc 9402 215 

budtool_db 

190 

Motif 

177 

mechanica 

164 

sgi5 

152 

ikos 

150 

ucberl 

147 

vlsi.v8r4_2 

145 

proe tmp 

138 

ftp 

134 

khoros 

134 

proe_13.0 

134 

calliope- verify 132 
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lib 

130 

iimura.be 

128 

gnu 

125 

bsd43 

115 

frame-4.0.3 

115 

svr4 

114 

Xllr5 

111 

chip-mdunit 

105 

motif 1 .2 

101 


user megs package megs total megs max capacity % used 
17963 15171 33135 59499 55% 
3766 2371 6138 9428 65% 
225 1602 1828 2484 73% 
5 725 731 1780 41% 

916 2566 3483 6208 56% 

auspex rama rhea gaea cronus: 

22875 22435 45315 79399 57% 


machine 

auspex 

rama 

rhea 

gaea 

cronus 


Exhibit C8 


Page 505 of 598 


From: Curtis Abbott [abbott@tallis] 

Sent: Monday, November 21, 1994 12:59 AM 

To: 'tonyOtaHis' 

Co: 'paulb@tallis'; 'rfgm@taHis'; 'graham@tallis'; 'tbr@tallis'; 'mouss@tallis' 
Subject: draft data sheet comments 

Tony - Here are some comments on your draft data sheet. I think this 
is a good approach and a useftil start. 

Overall reactions: 

1 . Your data sheet is confusing because it tries to talk about 
everything all at once. I think it would be better to build all the 
data sheets, so that the later ones can refer to the earlier ones. 
Just as we're going to build one product on another. I've started 
working on a contribution - a set of engineering driven data sheets 
for the Pandora-related products I think are on the table: the Pandora 
hardware, development software. Calliope add-in, sig gen software, sig 
analysis software. Pll try to have something next week sometime. 

2. Your data sheet contains technical inaccuracies. The spec 
development process needs to be based on both two kinds of specs, 
driven by engineering and marketing respectively. We (engineering) 
need to do better in producing a concise but complete engineermg 
spec. We've made various attempts, some of which you may not be 
aware of. 

The main inaccuracy is due to the fact that Calliope only has one 
video a/d, not 3. Also, the "analog bandwidth" is somewhat different 
for the video/RF ins and outs - some mix onto/off of carriers, some 
don't. Here are some notes towards a concise engineering spec of 

Calliope: 

Name Qty Bits SR BW Freq Notes 
Video in 1 8 l3.5Msps 0-6MHz baseband 
RFin 2 8 13.5Msps 0-6MHz 0-lOOOMHz 
Video out 3 8 13.5Msps 0-6MHz baseband 
RFout 2 8 13.5Msps O-6MH2 0-lOOMHz 

Audio in 3 16 1.69Msps 0-800KHz baseband 16-bit to SOKHz, then less 
Audio out 3 16 1.69Msps 0-800IGlz baseband 16-bit to SOKHz, then less 

Notes: 

The RF out DACs are actually driven at 216MHz, but I list the SR as 
13.5 anyway, because that's the maximum speed software can drive it 
(after that, the Calliope hardware upsamples it and puts on a carrier 
digitally). 

The RF in ADCs are actually driven at 108MHz, but the SR is 13.5 
because they aren't really observable until after the digital 
resampler, which outputs between SMSps and 13.5MSps. 

The video DACs could all be driven at 216MHz, but there would be a 
problem with ring bandwidth inside Calliope. I'm not sure how hard it 
would be to change Calliope to be more flexible here. (It would be a 
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metal change, though.) I assume a similar comment applies to the 
video ADCs at 108MHz. 

The frequency stability and accuracy of all these ins and outs will be 
directly related to that of the clock source driving Euterpe and 
Calliope. 

I believe the linearity spec on the audio i/o's depends on the 
bandwidth of the supplied signal, and that the 16 bits applies to 
audio signals. I dont know the rest of the curve though. Graham 
knows more about this. 
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From: tbr 

Sent: Monday, November 21 , 1994 10:37 AM 

To: 'dickson'; 'biliz'; 'mws'; Swoody' 

Cc: 'jeffm' 

Subject: Euterpe status 


Follow Up Flag: Follow up 
Flag Status: Red 


I'd like another short meeting at 1 1 today please to take stock of 
where we are. 

Tim 
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From: 
Sent: 
To: 

Subject: 


lisa 

Monday, November 21, 1994 11:44 AM 
'software-checkins-dist' 
stb/include/terp terp.h 


Update of /p/cvsroot /stb/include/terp 

In directory calliope : /usr/people/lisa/src/stb/include/terp 

Modified Files: 
terp.h 

Log Message; 

Moved the cerberus- control -register nb-level and memory- management -enable shift 
definitions near the other ones, and named them consistently. 


Exhibit C8 


Page 509 of 598 


From: iisa 

Sent: Monday, November 21 , 1994 12:04 PM 

To: 'Kleanthes Koniaris' 

Cc: 'guarino'; 'abbott'; 'gmo' 

Subject: Re: Missing opcodes? 


> Dear Hackers: 

> 

> I have found some opcodes in the terp-opc.c file that do not seem to 

> exist in the simulator's opcode-def s . h file; am I trying to do 

> something wrong/ stupid? 
> 

> " g4mux • 

> "gextractOi64 ' 

> "guextractil28 ' 

> *gextract0il28 ' 

> ''gexpand0i64 ' 

> " guexpando i64 ' 

> "gshlOil28' 

> "gshr0il28' 

> -gushr0il28' 

> **grotrOil28 ' 

> "'gmshrOil28 ' 

All of these are just synonyms for other instructions. The way to tell which is the 
"real" instruction is to choose the mnemonic which is the 
* first* given for a new opcode/mask pair. 

For example: 

{ "g.shuf flei", 0x20000000, OxffOOOOOC, "C=sa,b,h", I_PRRH, . . . 

{ "gshufflei4mux", 0x21000000, Oxff 0 00000, "C=A,B,h'', I_PPPH, . . . 

{ "g.shufflei.4mux" , 0x21000000, Oxff 000000, "C=A,B,h", I_PPPH, . . . 

{ "g4mux", 0x21000000, Oxff 000000, "C=A,B", • • • 

{ "g.4mux", 0X21000000, Oxff 000000, "C=A,B", I_PPP, . . . 

{ "gselectS", 0x22000000, Oxff 000000, "D=a,b,c", I_PRRR, . . . 

gshuf f lei4mux, g. shuf f lei . 4miix, g4mux, and g.4mux are all the SAME instruction. The only 
difference between the first two and the second two is that the assembler will fill-in the 
appropriate values (whatever they are) for the 'h' operand if you use the short-hand 
"g4mux". But in the architecture, there is just one instruction (call it anything you 

like) 

with a major opcode of 0x21. To simplify things in the simulator, we use the first string 
found "gshuf flei4mux" -- for the enumeration constant, ignore any (immediately 
following) names with the same opcode (and mask) , and then take the next opcode found 
( "gselectS" ) , and so on. 

Let me know if any of that didn't make sense. (The table is definitely a delicate piece 
of art! ;-) 

lisa 
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From: 
Sent: 
To: 

Subject: 


lisa 

Tuesday, November 22, 1994 12:17 PM 
'software-checkins-dist' 
gnu-tools/sim/terp execute.h 


update of /p/cvsroot/gnu-tools/sim/terp 

In directory calliope : /N/auspex/root/s6/lisa/src/gnu-tools/sim/terp 

Modified Files: 
execute . h 
Log Message: 

Cleaned-up some comments and added extern declaration for Bira_done() . 
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From: 
Sent: 
To: 

Subject: 


lisa 

Tuesday, November 22, 1994 12:18 PM 

'software-checkins-disf 

gnu-tools/si m/terp ir.c 


Update of /p/cvsroot/gnu-tools/sim/terp 

In directory calliope: /N/auspex/root/s6/lisa/src/giiu-tools/sim/terp 

Modified Files: 

ir . c 
Log Message : 

Moved handling of END_OCTLET from ir_io_read(} into ir_io_access { > so that either reading 
or writing causes simulation to end. 
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From; lisar (Lisa Robinson) 

Sent: Tuesday, November 22, 1994 5:51 PM 

To: 'path@ikos' 

Cc: 'tbr' 

Subject: warning message 


warning [2001001,6]: expand module euterpe because of not enough map or IIF files 
Lisa R. 
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From: cralg 

Sent: Wednesday, November 23, 1 994 11 :03 AM 

To: •agc@echidna.microunity.com'; 'solo' 

Cc: 'mnemo'; 'solo@MicroUnity.com' 

Subject: Re: IMMINENT DECISION: test mode change 


The proposal as it exists would be disasterous for the ability of Euterpe to use test mode 
to check the SRAM for defects, as it does not have the ability to generate arbitrary check 
patterns . 

Regards 
Craig 
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From: craig (Craig Hansen) 

Sent: Wednesday, November 23, 1994 12:03 PM 

To: 'agc@echidna.microunity.com'; 'solo' 

Cc: 'mnemo'; 'solo@iVlicroUnlty.com' 

Subject: Re: IMMINENT DECISION: test mode change 


The proposal as it exists would be disasterous for the ability of Euterpe to use test mode 
to check the SRAM for defects, as it does not have the ability to generate arbitrary check 
patterns. 

Regards 
Craig 
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From: solo (John Campbell) 

Sent: Wednesday, November 23, 1 994 1 :07 PM 

To: 'Craig Hansen' 

Cc: 'agc@MicroUnity,com'; 'mnemo'; 'solo@MicroUnity.com' 

Subject: Re: IMMINENT DECISION: test mode change 


as Craig Hansen was saying 

..The proposal as it exists would be disasterous for the ability ..of Euterpe to use test 
raode to check the SRAM for defects, as ..it does not have the ability to generate 
arbitrary check patterns. 

. .Regards 
. . Craig 

does this mean you like our proposal or not? 

or 

do you mean that euterpe is incapable of sending a bad check byte? 


regards, EMail solo@microunity.com 

solo a.k.a. John Campbell phone 408 734-8100 fax 408 734-8136 
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From: 
Sent: 
To: 

Subject: 


lisa 

Wednesday, November 23, 1994 3:39 PM 
'doi' 

Re: Question about the accuracy of minor cycle counts in terp 


> In one of the "regdepend' tests we noticed some cases in which the 

> output "atf ' claimed that two commits occured to a single register at 

> one time . 
> 

> Is this a bug or is there some reason to explain the behaviour? 

Sounds like a bug to me, but I don't know what/where it is. 
Can you point me at the test case? 


lisa 
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From: 
Sent: 
To: 

Subject: 


lisa 

Wednesday. November 23, 1994 3:53 PM 
'software-checkins-dist' 

gnu-tools/slm/terp cerberus.c decode.c memory.c memory, h v_mem.c 


update of /p/cvsroot/gnu-tools/sira/terp 

In directory calliope : /N/auspex/root/s6/lisa/src/gnu-tools/sim/terp 

Modified Files: 

cerberus.c decode.c memory.c memory. h v_mem,c Log Message: 

Reworked lots of the cache simulation to more closely resemble the 

hardware : 

- There are no caches until memory- management is enabled. 

- Zero is now a valid cache size. 

- At initialization, the sram is allocated as buffer-size + cache-size, 
and all is usable as buffer until memory- management is enabled, at which 
point the cache- size portion at the end (higher address) of the buffer 
"becomes" the cache . 

- If REALLY_ACCURATE . . . , the cache tags are initialized to random values. 

- The protection field of the icache tag has been updated to latest uarch. 
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From: 
Sent: 
To: 

Subject: 


lisa 

Wednesday. November 23, 1994 3:55 PM 
'doi' 

Re: Question about the accuracy of minor cycle counts in terp 


> I have the .exe and the .exe. trace files in -doi/export with the 

> prefix "regdepend_r6403_0 ' . 

> 

> The source has been punted, unfortunately. 

> 

> What else would make looking at this easier? 

That should be enough. If it turns out not to be, I'll let you know... 


thanks , 
lisa 
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Subject: 


Sent: 

To: 

Cc: 


From: 


lisa 

Wednesday, November 23, 1994 5:06 PM 
'doi' 

'mws'; 'gmo' 

Re: Question about the accuracy of minor cycle counts in terp 


> In one of the "regdepend' tests we noticed some cases in which the 

> output "atf ' claimed that two commits occured to a single register at 

> one time. 

This is happening when we have two instructions with the same destination register, but 
with different latencies, and the two instructions finish at the same time. We 
anticipated this problem somewhat, but were not sure what the hardware was going to do. 
Does an instruction which writes a register always stall until that register is available? 
(I.e., an instruction has a dependency on all of its source registers *and* on its 
destination register (s) . ) If not, what does happen? 


lisa 
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From: 
Sent: 
To: 

Subject: 


lisa 

Wednesday, November 23, 1994 5:37 PM 
'software-checkins-disf 
gnu-tools/sim/terp cerberus.c 


update of /p/cvsroot /gnu-tools/sim/terp 

In directory calliope: /N/auspex/root/s6/lisa/src/gnu-tools/sim/terp 

Modified Files: 

Cerberus . c 
Log Message : 

Believe the cache sizes in the value written to the cerberus control register when the 
memory-management- enable bit is set, unless an overriding size (via the command line or 
gdb "set sim" command) has been given. 
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Subject: 


Sent: 

To: 

Cc: 


From: 


doi (Derek Iverson) 

Wednesday, November 23, 1994 6:56 PM 
'gmo': 'guarino'; 'sandeep'; 'jeffm'; 'wayne'; 'gregg' 
'hestia' 

Software Bring-up Meeting IVIinutes - Nov 23, 1994 


Software Bringup Meeting 


November 23, 1994 


Next Meeting: 


November 30 at 10:00 am. 


Review of CBI related issues. 

Review of the bring-up section of the euterpe schedule. 


Attendees: jeffm, guarino, gmo, wayne, doi, sandeep 


New Action Items 


Item: What is dependent on SC within Euterpe? ROM & LEDs? 

Reads of cerberus registers? 
Who : wayne 

Status: [11/23] New. 

Item: Continue trying to find either source code for parallel drivers 

or descriptions of hardware so we can write out own. 
Who: gmo sgi machines 
Who: doi sun machines 

Who: wayne HPIB driver source or HW desc. for either Sun or SGI. 
Status: [11/23] New. 

Review of Action Items 


Item: Implement parallel port device drivers for sun and sgi. 
Who: sandeep, doi 

Status: on hold pending discussion of CBi at the Pandora Meeting (11/18) 

Jerry K. found a driver on the Liniox machine that appeared 
to handle interrupt based transactions. 

On achilles (if you have an id on the machine) you can see 
the code on /usr/src/linux/drivers/net/plipc . 

Item: Write up a plan for virtual devices and their interaction with 
gdb. 

Who : gmo 
Status: Done. 

Item: Build scripting/UI capabilities above gdb for regression tests. 
Who : doi 

Status: on hold until the the boot, gdb boot stub, and virtual devices 

are complete, (estimated start date of 12/23) 

Item: Get durations for items on the schedule for hestia function test 
Who : doi 
Status: Done. 

Item: Identify our brinp-up tools and malce sure we have plans for how 
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we will debug them. 
Who : doi , et . al . 
Status : Done . 

Item: Determine which pins can be software controlled on each of the 
sun port. 

The pins that are controlled are: select in, form feed, initialize 

Who: doi 

Status : Done . 

Item: Create performance test plan 
Who: jeffm, guarino 
Status: no progress 

Item: Add Unix- like tests to software acceptance tests. 

Who; guarino 

Status: no progress 

Item: CerbROM support from terp. 
Who : gmo , sandeep 
Status: nearly done. 

Item: Simulator needs to understand "reset' 
Who ; gmo 

Status: in progress (due 12/23) 

Item: Implement and bring-up boot, gdb boot stub, and virtual device 

support on the software simulator. 
Who : sandeep/gmo 

Status: in progress (due 12/23) 


General Discussion 


Typical discussion about CBI. . . . 
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From: tbr 

Sent: Thursday, November 24, 1994 2:36 PM 

To: 'solo (John Campbell)' 

Cc: 'agc@MlcroUnlty.com'; Craig Hansen; 'mnemo'; 'solo@MicroUnity.com' 

Subject: Re: IMMINENT DECISION: test mode change 
Follow Up Flag: Follow up 

Flag Status: Red 


John Campbell wrote (on Wed Nov 23): 

as Craig Hansen was saying 

..The proposal as it exists would be disasterous for the ability 
..of Euterpe to use test mode to check the SRAM for defects, as 
..it does not have the ability to generate arbitrary check patterns, 

..Regards 

..Craig 

does this mean you like our proposal or not? 
or 

do you mean that euterpe is incapable of sending a bad check byte? 

Euterpe will not send a bad check byte. Since this version on 
Mnemosyne will not have RAM redundancy, it's not clear to me how 
important it would be to have a fast way to test the RAM irom Euterpe. 
As I understand the interest here it's comming purely from a component 
test perspective. 

Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Tim B. Robinson [tbr@gaea.microunity.com] 
Thursday, November 24, 1994 2:36 PM 
•John Campbell' 

'agc@MlcroUnity.com'; Craig Hansen; 'mnemo@gaea.microunity.com'; 
'so)o@MicroUnity.oom' 

Re: IMMINENT DECISION: test mode change 


John Campbell wrote (on Wed Nov 23) : 

as Craig Hansen was saying 

. .The proposal as it exists would be disasterous for the ability 
. .of Euterpe to use test mode to check the SRAM for defects, as 
..it does not have the ability to generate arbitrary check patterns, 

. .Regards 
. .Craig 

does this mean you like our proposal or not? 


do you mean that euterpe is incapable of sending a bad check byte? 

Euterpe will not send a bad check byte. Since this version on Mnemosyne will not have RAM 
redundancy, it's not clear to me how important it would be to have a fast way to test the 
RAM from Euterpe. 

As I understand the interest here it's comming purely from a component test perspective. 


or 


Tim 
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From: geert (Geert Rosseel) 

Sent: Friday, November 25, 1994 1:59 PM 

To: 'rich'; 'tbr'; 'wampler' 

Subject: Euterpe PLL's 


Hi, 

I cannot remember how we finally resolved the PLL issue with the 
knob-settings. I though the latest proposal was to run the PLL's 
with knob=6 and a tighter cycle time. Is that what's being done ? 

Geert 
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From: 
Sent: 
To: 

Subject: 


rich (Rich McCauley) 

Friday, November 26, 1994 2:29 PM 

'tbr'; 'wampler'; 'geert' 

Re: Euterpe PLL's 


Yes, Both the gardswarts have been reconstructed using rcdssS and slightly tighter timing 
numbers . 


> From geert Fri Nov 25 11:58:53 1994 

> Date: Fri, 25 Nov 1994 11:58:52 -0800 

> From: geert (Geert Rosseel) 

> To: rich, tbr, wampler 

> Subject: Euterpe PLL's 

> Content -Length: 212 


> Hi, 
> 

> I cannot remember how we finally resolved the PLL issue with the 

:> knob- settings . I though the latest proposal was to run the PLL's with 

> knob=6 and a tighter cycle time. Is that what's being done ? 


rich 


> 


> Geert 


> 


> 
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Subject: 


Sent: 

To: 

Cc: 


From: 


woody (Jay Tomlinson) 

Friday, November 25. 1994 5:17 PM 

'euterpe' 

•jeffm'; 'bobm' 

Changed to 1 1/6 DECISION: event daemon 


Below is the mail from tbr describing the implementation of the Event Daemon register. 

Recently, Scott Furman pointed out that using the NB slow peripheral queue is a problem 
because an Event Daemon store could be delayed waiting for a cerberus operation to 
complete. Thus, deadlines are missed. In order to fix this problem, there will be an Event 
Daemon register per channel. This allows NB to put these operations into the appropriate 
Hermes Channel queue. 
Event 

Daemon stores will now be processed in order by the Hermes Channel. In order to reduce the 
number of bits that are required to be decoded by NB, the Event Daemon register will be 
put into a unique space (hw currently implemented using 
space==0x81 until Craig re-assigns) , 

Following Craig's suggestion, the Event Daemon register store data will no longer be used 
to identify the event register. Now only the address. The address is decoded as follows: 

47:40 space (hw currently uses 0x81) 

39:37 channel 

36:35 module address 

34:3 octlet address of event register 
Other than the above changes, the description below is still accurate. 


Tim B. Robinson wrote (on Sun Nov 6) : 

The following is a description of what is being implemented 
for the Event Daemon register. 

A fixed Hermes sequence ID of 7 will be used for blocking reads. This 
sequence ID will not be available for normal operations, but multiple 
blocking reads to different devices on the same ring can be 
outstanding simultaneously, each with sequence ID 1, distinguished by 
the module address. Thus up to 7 normal operations and 4 blocking 
reads can be outstanding on each channel simultaneously. The 
collision detection which prevents multiple outstanding transactions 
to the same address in the same device will not apply to blocking 
reads. This is necessary because the conflict check is only 
approximate, looking at 6 low order address bits, and without this 
exclusion, normal operations could be held off pending a blocking read 
return. 

Stores to the Event Daemon register go via NB, so back to back stores 
from different threads to event registers in multiple devices is 
supported. The Event Daemon register is decoded from the "slow 
peripheral" queue, and communicates directly with the appropriate 
Hermes channel . It is thus possible for an Event Daemon store to be 
processed ahead of a normal load or store previously issued to the 
same Hermes channel . 

Hardware keeps track of pending blocking reads so duplicates can be 
suppressed. This deals with the problem of multiple blocking reads 
initiated by different threads after multiple interrupts to different 
threads have been returned together . Software therefore does not have 
to provide independent synchronization to ensure only one blocking 
read is posted. If an interrupt is permanently masked off in the 
Euterpe event register and there is a possibility that for some reason 
this interrupt causes the blocking read to return, a deadlock can )3e 


Jay 
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avoided by having a watchdog routine periodically issue another 
blocking read. 

Software is still responsible for posting at least one blocking 
read for each interrupt received, ie there is no automatic hardware 
rescheduling of blocking reads. There is a possibility of duplicate 
events being signaled if another blocking read is issued by another 
thread before bits have been cleared in the peripheral device event 
register. This can be mitigated by always clearing the peripheral 
device event register before the corresponding bits in the Euterpe 
event register. However, because of possible delays in processing the 
store over the Hermes channel, there may still be a race here. 
If so, software will have to be able to handle it. 

This implementation does not directly address the problem of a low 
priority interrupt return blocking a high priority interrupt up to the 
point where the new blocking read is issued. 
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From: tbr 

Sent: Saturday, November 26, 1 994 1 0:32 AM 

To: 'geert (Geert Rosseel)' 

Cc: 'rich'; 'wampler' 

Subject: Euterpe PLL's 

Follow Up Flag: Follow up 

Flag Status: Red 


Geeit Rosseel wrote (on Fri Nov 25): 


Hi. 

I cannot remember how we finally resolved the PLL issue with the 
knob-settings. I though the latest proposal was to run the PLL's 
with knob=6 and a tighter cycle time. Is that what's being done ? 

>From the proteus BOM log: 


revision 5.603 

date: 1994/11/16 14:02:01 LT; author: wampler; state: Exp; lines: +2 -2 
Release Target: proteus/gardswarts/pl_euh_logic 

Set target cycle time from lOOOpS down to 800pS to compensate for going from 
resistor code 5 to resistor code 6. 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Saturday, November 26, 1994 10:32 AM 

•geert (Geert Rosseel)' 

'rich'; 'wampler' 

Euterpe PLL's 


Geert Rosseel wrote (on Fri Nov 25) : 


Hi, 


I cannot remember how we finally resolved the PLL issue with the 
knob- settings . I though the latest proposal was to run the PLL's 
with knob=6 and a tighter cycle time. Is that what's being done ? 

>From the proteus BOM log: 


revision 5.603 

date: 1994/11/16 14:02:01 LT; author: wampler; state: Exp; lines: +2 -2 Release Target: 
pro t eus / gards war t s /p l_euh_l ogi c 

Set target cycle time from lOOOpS down to 800pS to compensate for going from resistor code 
5 to resistor code 6. 
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From: 
Sent: 
To: 

Subject: 


hopper (Mark Hofmann) 

Saturday, November 26, 1994 11:08 AM 

'Geert Rosseel' 

Re: .pirn file in gf 


Geert Rosseel writes: 
Hi Mark, 

In the snapshot : 
/n/auspex/s41/euterpe-snapshot/euterpe/verilog/bsrc/gf 

there seems to be a problem with the Makefile that creates gf-base.pira 

In gf .pirn ( the source) , there are a bunch of spacer cells to create 
a 20 atom gap in the middle. However, these are not in gf-base.pira. 


Technically speaking this is called a "bug". It's been fixed- what version of 
proteus/Makef ile , rules did you use to create gf? The latest released version (released at 
22:18 on 23 Nov) should fix this, I'm running gf now and it looks good so far. I noticed 
that the Os cells are missing in _all_ passes except the first in the snapshot. In my area 
they are present in pass2 and 

pass3 and in this iteration of "iter" (I don't know how many gf takes) . 
So, 

I think the bug is fixed, [You can check -hopper/chip/euterpe/verilog/bsrc/gf 
for results . ] 


Geert 


Hi Geert, 


-mark 
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From: 


tbr 


Subject: 


Sent: 


To: 


Cc: 


Saturday, November 26, 1994 4:26 PM 
'torn' 

'geert'; 'wampler' 
leafcell problem 


Follow Up Flag: Follow up 
Flag Status: Red 


I have bee re-njiming the make m the proteus snapshot to pick up 
some changes in the latest BOM. 

I see the following which looks serious to me. Is this just one of 
the known failures? 

VERCON Version 7.1.20 of March 30, 1994 

...reading nets... 

24 Nets Read 
...reading components... 

68 Components Read 
...reading physical types... 

9 Physical Types Read 
...reading logical types... 

***• routing progress ~ 0; no routing information in dff 

Terminated at : 94/1 1/26 14:22:10 
Elapsed CPU time : OHrs OMins OSecs 
Elapsed wall clock time : OHrs OMins OSecs 

*** gastatus detects error with vercon (see /usr/tmp/leafinold.xbmuxfCb2dhl6s) 
gmake[4]: *** [/n/auspex/s23/euteipe-proteus-cp/compass/leafi\bmuxffb2dhl6s.ly] Error 1 
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From: tbr (Tim B. Robinson) 

Sent: Saturday, November 26, 1994 4:26 PM 

To: 'torn' 

Cc: 'geert'; 'wampler* 

Subject: leafcell problem 


I have bee re- running the make in the proteus snapshot to pick up some changes in the 
latest BOM. 

I see the following which looks serious to me. Is this just one of the known failures? 
VERCON Version 7.1.2 0 of March 30, 1994 

. . .reading nets. , . 

24 Nets Read 
. . .reading components. . . 

68 Components Read 
. . . reading physical types . . . 

9 Physical Types Read 
. . . reading logical types . . . 

♦*** routing progress = 0; no routing information in dff 


94/11/26 14:22:10 

0 Hrs 0 Wins 0 Sees 

0 Hrs 0 Mins 0 Sees 


Terminated at 
Elapsed CPU time 
Elapsed wall clock time 
*** gastatus detects error with vercon {see 
/usr/tmp/leafmold. xbmuxf fb2dhl6s) 
gmake [4] ; *** 

[/n/auspex/s23/euterpe-proteus-cp/compass/leaf /xbmuxf fb2dhl6s . ly] Error 1 
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From: 


tbr 


To: 


Sent: 


Subject: 


Cc: 


Saturday, November 26, 1994 8:19 PM 
'brianr; •fwo' 
'bpw'; 'geerf; 'rich' 
Pin name problem 


Follow Up Flag: Follow up 
Flag Status: Red 


I cannot get the build to run to completion in the proteus snapshot 
after updating to the latest BOM. The problem is relate to the 
logicO/1 pin name change. Something does not appear to have 
been updated. Please let me know as soon as you understand what is 
the cause, so I can pick up the fix and continue the build. 
For reference, there is a faW log of the problem at the end of 
/N/auspex/root/s23/euterpe-proteus-cp/makerrs 

Here's the interesting bit: 

<lnk>#l ERROR(145): Pin name does not exist 
Drawing: "'XBC0iDF4S".SPICE.l.l 

No parameters 
Body: "R50M" (Path="8P") 
Unfoundpin: "LOGIC 1_AB0PF" 

Drawing: "lOCLKWART". SPICE. 1.1 

No parameters 
Body: "XBC01DF4S" (Path-MP") 
Pins of the bod^: 

"VRR"<2..0> 

"VII" 

"LOGICI_0P" 
"LOGIC0_0P" 


<lnk>#2 ERROR(145): Pin name does not exist 
Drawing: "XBC01DF4S".SPICE.1.1 

No parameters 
Body: "BJT" (Path="7P") 
Unfound pin: "LOGIC0_AB0PF" 

Drawing: "lOCLK WART". SPICE. 1 . 1 

No parameters 
Body: "XBC01DF4S" (Path="4P") 

MicroUnity Spice Interface Version 1 .93 

No Copyright (C) 1990 Valid Logic Systems, Inc. 

Processing Scald directories (00:00:0 1 .76) 

Calling ValidCompiler ... 

(00:00:49.46) 

Fatal error(s) found while compiling 

Please correct the design and rerun the program 
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MicroUnity Spice Interface run on Nov 26 18:14:20 1994 
DESIGN NAME : 'lOBYTE' 

DESIGN COMPILATION ON Nov 26 18:14:21 1994 


2 errors detected 
No oversight detected 
1 warnings detected 
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From: tbr (Tim B. Robinson) 

Sent: Saturday, November 26, 1 994 8: 1 9 PM 

To: 'brianl'; 'fwo' 

Cc: 'bpw'; 'geert'; 'rich' 

Subject: Pin name problem 


I cannot get the build to run to completion in the proteus snapshot after updating to the 
latest BOM. The problem is relate to the 

logicO/l pin name change. Something does not appear to have been updated. Please let me 
know as soon as you understand what is the cause, so I can pick up the fix and continue 
the build. 

For reference, there is a full log of the problem at the end of 
/N/auspex/root / s2 3 / euterpe-prot eus - cp/makerrs 

Here's the interesting bit: 

<lnk>#l ERROR (145) : Pin name does not exist 
Drawing: "XBC01DF4S" . SPICE. 1 . 1 

No parameters 
Body: "R50M" (Path="8P") 
Uhfound pin: "LOGIC1_ABOPF" 

Drawing : " I OCLKW ART " . S P I CE . 1 . 1 

No parameters 
Body: "XBC01DF4S" (Path="4P"} 
Pins of the body: 

"VRR"<2. . 0> 

"VII" 

"LOGIC1_OP" 
"LOGICO OP" 


<lnk>#2 ERROR {14 5) : Pin name does not exist 
Drawing : "XBC01DF4S " . SPICE . 1 . 1 

No parameters 
Body : " B JT " ( Path= " 7 P " ) 
Unfound pin: "LOGIC0_AB0PF" 

Drawing : " lOCLKWART" . SPICE . 1 . 1 

No parameters 
Body: "XBC01DF4S" (Path="4P") 

MicroUnity Spice Interface Version 1.93 No Copyright (C) 1990 Valid Logic Systems, Inc. 

Processing Scald directories (00:00:01.76) 
Calling ValidCompiler . . . 
(00:00:49.46) 

Fatal error (s) found while compiling 

Please correct the design and rerun the program 

MicroUnity Spice Interface run on Nov 26 18:14:20 1994 
DESIGN NAME : ' lOBYTE ' 

DESIGN COMPILATION ON Nov 26 18:14:21 1994 


2 errors detected 
No oversight detected 
1 warnings detected 
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From: briani {Brian Lee) 

Sent: Saturday, November 26, 1 994 11 :46 PM 

To: Tim B. Robinson' 

Cc: 'fwo (Fred Obermeier)'; 'bpw {B. P. Wong)'; 'geert (Geert Rosseel)'; 'rich (Rich McCauley)'; 

'torn (Thomas Laidig)' 
Subject: Re: Pin name problem 


Tim B. Robinson writes: 

I cannot get the build to run to completion in the proteus snapshot 
after updating to the latest BOM. The problem is relate to the 
logicO/1 pin name change. Something does not appear to have been 
updated. Please let me know as soon as you understand what is the 
cause, so I can pick up the fix and continue the build. 

Based on comments in the cvs log, I opened and wrote out the schematic for ioclkwart to 
"pick-up the new pin names". My local copy of the schematic now passes the ged2verilog 
invocation, I have committed and released this version of ioclkwart. 

Please let me know if this truly fixes the problem or if it only makes matters worse. 
Brian 

For reference, there is a full log of the problem at the end of 
/N/auspex/ root /s2 3 /euterpe- proteus -cp/makerrs 

Here's the interesting bit: 

<lnk>#l ERROR (145) : Pin name does not exist 
Drawing : "XBC01DF4S " , SPICE .1.1 

No parameters 
Body: "R50M" (Path="8P") 
Unfound pin: "LOGIC1_ABOPF" 

Drawing : " IOCLKWART " . SPICE .1.1 

No parameters 
Body: "XBC01DF4S" (Path="4P") 
Pins of the body: 

"VRR"<2. .0> 

"VII" 

''IjOGIC1_0P" 
"LOGIC0_0P" 


<lnk>#2 ERROR (145) : Pin name does not exist 
Drawing : "XBC01DF4S" . SPICE .1,1 

No parameters 
Body: "BJT" (Path="7P") 
unfound pin: "LOGICO_ABOPF" 

Drawing : " IOCLKWART " . SPICE .1.1 

No parameters 
Body: "XBC01DF4S" (Path="4P") 

MicroUnity Spice Interface Version 1.93 No Copyright (C) 1990 Valid 
Logic Systems , Inc . 

Processing Scald directories (00:00:01.76) 
Calling ValidCompiler . . . 

{00 :00 :49.46) 

Fatal error (s) found while compiling 

Please correct the design and rerun the program 
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MicroUnity Spice Interface run on Nov 26 18:14:20 1994 
DESIGN NAME : 'lOBYTE' 

DESIGN COMPILATION ON Nov 26 18:14:21 1994 


2 errors detected 
No oversight detected 
1 warnings detected 


Brian L. 
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From: Geert Rosseel [geert@rhea] 

Sent: Sunday, November 27, 1994 1:14 PM 

To: 'geert@rhea' 

Subject: pager log message 


page from geert to geert; 

pagerae gtnake geert_euterpegards start :Nov_27_10 : 48 end: Nov_27_ll:12 exit 
1 
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Subject: 


Sent: 

To: 

Cc: 


From: 


John Campbell [solo@gaea.microunity.com] 
Monday, November 28, 1994 9:14 AM 
Tim B. Robinson' 

'agc@MicroUnlty.com'; Craig Hansen; 'mnemo@gaea.microunity.com'; 
'solo@MicroUnity.com' 

Re: IMMINENT DECISION: test mode change 


as Tim B. Robinson was saying 


John Campbell wrote (on Wed Nov 23) : 

as Craig Hansen was saying 

..The proposal as it exists would be disasterous for the ability 
..of Euterpe to use test mode to check the SRAM for defects, as 
..it does not have the ability to generate arbitrary check patterns. 

. .Regards 
. . Craig 

does this mean you like our proposal or not? 


do you mean that euterpe is incapable of sending a bad check byte? 

. .Euterpe will not send a bad check byte. Since this version on . .Mnemosyne will not have 
RAM redundancy, it's not clear to me how ..important it would be to have a fast way to 
test the RAM from Euterpe . 

. .As I understand the interest here it's comming purely from a component ..test 
perspective . 

. .Tim 

That's correct. We don't intend to have a test mode from euterpe. we are also looking at 
BIST which could possibly be fired off from cerberus as a power on RAM test. 
Implementation is still in definition phase. We invision a checkerboard/checkerboardbar 
and an address uniqueness test of some kind, this would go right at the beginning of the 
RAM pipeline. 


regards, EMail soloSmicrounity . com 

solo a.k.a. John Campbell phone 408 734-8100 fax 408 734-8136 


or 
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Subject: 


Sent: 

To: 

Cc: 


From: 


solo (John Campbell) 

Monday, November 28, 1994 9:14 AM 

Tim B. Robinson' 

'agc@MlcroUnity.com'; Craig Hansen; 'mnemo'; 'solo@MlcroUnity.com' 
Re: IMMINENT DECISION: test mode change 


as Tim B. Robinson was saying 


John Campbell wrote (on Wed Nov 23) : 

as Craig Hansen was saying 

. .The proposal as it exists would be disasterous for the ability 
, .of Euterpe to use test mode to check the SRAM for defects, as 
..it does not have the ability to generate arbitrary check patterns. 

. .Regards 
. . Craig 

does this mean you like our proposal or not? 


do you mean that euterpe is incapable of sending a bad check byte? 

. .Euterpe will not send a bad check byte. Since this version on . .Mnemosyne will not have 
RAM redundancy, it's not clear to me how ..important it would be to have a fast way to 
test the RAM from Euterpe . 

..As I understand the interest here it's comming purely from a component ..test 


That's correct. We don't intend to have a test mode from euterpe. We are also looking at 
BIST which could possibly be fired off from cerberus as a power on RAM test. 
Implementation is still in definition phase. We invision a checkerboard/ checkerboardbar 
and an address uniqueness test of some kind, this would go right at the beginning of the 
RAM pipeline. 


regards / EMail solo@microunity.com 

solo a.k.a. John Campbell phone 408 734-8100 fax 408 734-8136 


or 


perspective. 


. .Tim 
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From: Eric Murray [ericm@MicroUnityxom] 
Sent: Monday, November 28, 1994 10:01 AM 
To: •sysadm@MicroUnity.com' 
Subject: disk usage report 

For directories over 100 megs: 
user's info: 


Dnani 

1458 

hopper 

1UB4 

chip 

1020 

geert 

yjo 

craig 

880 

fwo 

851 

tbr 

741 

jsw 

684 

hchu 

625 

dickson 

619 

gmo 

603 

rozen 

577 

vanthof 


h 

507 

sandeep 

487 

brendan 

479 

vijay 


rocky 

453 

qua 

434 

brian 

417 

wampler 

403 

veena 

382 

fur 

333 

doi 

323 

Knp 


age 

282 

jefftn 

279 

ken 

279 

toni 


wingard 

261 

ras 

259 

the 

251 

fung 

220 

woody 

217 

iimura 

213 

rich 

206 

peter 

206 

bill 

202 

haim 

191 

gregg 

190 

lisar 

189 

bpw 

187 

hessam 

184 

al 

181 

mws 

176 

guarino 

173 

ericm 

172 

solo 

172 

Vandyke 

170 


Exhibit C8 


Page 543 of 598 


cox 

162 

billz 

162 

albers 

161 

lisa 

159 

karzes 

145 

dane 

143 

randy 

142 

chuck 

139 

jeff 

135 

pmayer 

134 

octtools 

130 

tomho 

130 

mikew 

127 

fambro 

123 

yves 

120 

paulb 

117 

ong 

115 

hayes 

111 

larryk 

103 

joe 

101 


packages info: 
ch ip-euterpe-buil 2118 
calliope 1579 
news 1185 
euterpe- verify 1011 
soft-src 948 
chip-archive 888 
orchissnap 811 
chip-proteus 809 
losf-build 776 
calliope-disk2 730 
cadence 633 
ptolemy 628 
archives 608 
Sim 572 
osf 564 
cadence.hp 552 
soft 538 
calliope 1 -fractur 487 
chip-calliope 484 
chip-terpsichore 475 
sgi 377 
xllr5_ken_p26 329 
castor-retry 325 
chip-archive-terp 3 1 8 
calliope-overflow 297 
mips-4.52 282 
chip-archive-mnem 259 
Xllr4 228 
bsd 222 
cadence_doc 221 
synopsys 216 
cadence_doc_9402 2 1 5 
budtool 191 
Motif 177 
mechanica 164 
lib 163 
sgi5 152 
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ikos 150 

ucberl 147 

vlsi.v8r4_2 145 

ftp 134 

khoros 1 34 

proe 13.0 134 
calliope-veriiy 132 

iimura.be 128 

gnu 125 

bsd43 115 

frame-4.0.3 115 

svr4 1 1 4 

Xllr5 in 

chip-mdunit 105 

motifl.2 101 


machine user megs package megs total megs max capacity % used 

auspex 20672 19140 39812 59499 66% 

rama 3427 2106 5534 9428 58% 

rhea 224 1603 1828 2484 73% 

gaea 5 1601 1607 1780 90% 

cronus 922 2585 3507 6208 56% 

auspex rama rhea gaea cronus: 

25250 27035 52288 79399 65% 
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From: woody (Jay Tomlinson) 

Sent: Monday. November 28, 1 994 1 0:37 AM 

To: Jeffm' 

Cc: 'lisar; 'tbr' 

Subject: eventdaemoneasy 

Jeff, 

The euterpe event register is never cleared. After reset it is X's and since it 
is never written, it will be read out as X's causing the passl_wait loop to go 
to X's. 

Jay 
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From: 
Sent: 
To: 

Subject: 


lisa 

Monday, November 28, 1994 10:59 AM 
'softwa re-check i n s-d i st' 
gnu-tools/sim/terp ir.c 


Update of /p/cvsroot /gnu-tools/sim/terp 

In directory calliope: /N/auspex/root/s6/lisa/src/gnu-tools/sim/terp 

Modified Files: 

ir.c 
Log Message: 

In ir_io_init { ) , be sure to free any old disk or tape names . 
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From: tbr 

Sent: Monday, November 28, 1 994 1 1 :02 AM 

To: 'fwo (Fred Obermeier)' 

Cc: 'bpw'; 'geert' 

Subject: Celltest rerun. 

Follow Up Flag: Follow up 

Flag Status: Red 


Fred Obermeier wrote (on Sun Nov 27): 
Tim, 

The io01ffdh6s and tlbmlcol have never been run through celltest. 

ril start rerunning the other cells, though I suspect we're going to get 

lots more celltest failures now that the rcode and voltage comparison levels 

have changed. The Csyn/Celltest meetings never got around to discussing 

the problems with the voltage comparison ranges we are currently running with. 

It concerns me that tlbmlcol should never have been run, since the TLB 
in some form has been essentially 'done' for about a year now. I 
thought for custom structures csyn and celltest we pre-requisites to 
running LVS. I realise recent changes may have invalidated tiiose 
results, but clearly we need a big push here to get euterpe clean. 

Tim 
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Subject: 


Sent: 

To: 

Cc: 


From: 


tbr (Tim B. Robinson) 

Monday. November 28. 1994 11:02 AM 

'fwo (Fred Obermeier)' 

'bpw'; 'geert' 

Celltest rerun. 


Fred Obermeier wrote (on Sun Nov 27) : 


Tim, 


The ioOlffdhes and tlbmlcol have never been run through celltest. 

I'll start rerunning the other cells, though I suspect we're going to get 

lots more celltest failures now that the rcode and voltage comparison levels 

have changed. The Csyn/Celltest meetings never got around to discussing 

the problems with the voltage comparison ranges we are currently running with. 

It concerns me that tlbmlcol should never have been run, since the TLB in some form has 
been essentially 'done' for about a year now. I thought for custom structures csyn and 
celltest we pre- requisites to running LVS . I realise recent changes may have invalidated 
those results, but clearly we need a big push here to get euterpe clean. 


Tim 
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Subject: 


From: 
Sent: 


To: 


Cc: 


tbr 

Monday, November 28, 1994 11:05 AM 
•woody (Jay Tomlinson)' 
•jeffm'; 'llsar' 
eventdaemoneasy 


Follow up Flag: Follow up 
Flag Status: Red 

Jay Tomlinson wrote (on Mon Nov 28): 
Jeff, 

The euterpe event register is never cleared. After reset it is X's and since it 
is never written, it will be read out as X's causing the passl_wait loop to go 
to X's. 

You have to write the event register and mask registers prior to 
leaving event mode. 


Tim 
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From: bpw (B. P. Wong) 

Sent: Monday, November 28, 1 994 11 : 33 AM 

To: 'fwo'; 'tbr' 

Cc: 'bpw'; 'geert' 

Subject: Re: Celltest rerun. 


> Fred Otaermeier wrote (on Sun Nov 27) : 
> 

> Tim, 
> 

> The ioOlffdhSs and tlbmlcol have never been run through celltest. 

> I'll start rerunning the other cells, though I suspect we're going 

> to 
get 

> lots more celltest failures now that the rcode and voltage 

> comparison 
levels 

> have changed. The Csyn/Celltest meetings never got around to 

discussing 

> the problems with the voltage comparison ranges we are currently 
running with. 

> 

> It concerns me that tlbmlcol should never have been run, since the TLB 

> in some form has been essentially 'done' for about a year now, I 

> thought for custom structures csyn and celltest we pre- requisites to 

> running LVS. I realise recent changes may have invalidated those 

> results, but clearly we need a big push here to get euterpe clean. 
> 

> Tim 
> 

The TLB passed celltest more than a year ago. We have been through this six months ago 
and this argument is back again! We used to have the automatic checkin of the ctgold 
directory to show that it has been done. Has that directory been destroyed? 

bpw 
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Subject: 


Sent: 

To: 

Cc: 


From: 


fwo (Fred Obermeier) 

Monday, November 28, 1994 11:41 AM 

■tbr' 

'bpw'; 'fwo'; 'geert' 
Re: Celftest rerun. 


Tim wrote, 

Fred Obermeier 


wrote (on Sun Nov 27) : 


Tim, 


The ioOlffdhSs and tlbmlcol have never been run through celltest. 

I'll start rerunning the other cells, though I suspect we're going to get 

lots more celltest failures now that the rcode and voltage comparison levels 

have changed. The Csyn/Celltest meetings never got aro\and to discussing 

the problems with the voltage comparison ranges we are currently running with. 

It concerns me that tlbmlcol should never have been run, since the TLB 
in some form has been essentially 'done' for about a year now. I 
thought for custom structures csyn and celltest we pre-rec[uisites to 
running LVS. I realise recent changes may have invalidated those 
results, but clearly we need a big push here to get euterpe clean. 


Actually, there is another possibility for the current lack of these celltest results. 
Previous results are usually wiped away manually before running the final top-level 
celltest run. Also, previous results are invalidated by any change to the csyn. rules, 
csyn. signame, or celltest* stim voltage files. Since I've been making lots of changes to 
these files over the last few months , previous celltest runs should be rerun anyway. 


Tiro 


Fred. 
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From: bpw (B. P. Wong) 

Sent: Monday, November 28. 1 994 11 :44 AM 

To: 'two'; 'tbr' 

Cc: 'bpw'; 'geert' 

Subject: Re: Celltest rerun. 


> > It concerns me that tlbmlcol should never have been run, since the 

> > TLB in some form has been essentially 'done' for about a year now. 

> > I thought for custom structures csyn and celltest we pre- requisites 

> > to running LVS . I realise recent changes may have invalidated those 

> > results, but clearly we need a big push here to get euterpe clean. 

> > 

> > Tim 

> > 

:> The TLB passed celltest more than a year ago. We have been through 

> this six months ago and this argument is back again I We used to have 

> the automatic checkin of the ctgold directory to show that it has been 

> done. Has that directory been destroyed? 

> 

> bpw 
> 

The following is log of the celltest on tlbmlcol that is still in 
~chip/proteus//celltest/ctgold. 500v/tlbmlcol/log. ct : 

* time: Tue Dec 28 17:17:16 1993 

* user: bpwsfrodo 

* command: /a/muse/bin/ sun4 /celltest -chip proteus -maxstates 2048 
- tstep 

* command: le-9 -conditions 500v modS.sp 


passed swing conformance test on tlbmlcol. trO 
massage succeeded 

Riinning ttcmpr tlbmlcol: logic compare passed on tlbmlcol 

passed celltest tlbmlcol 

Updating gold directory ctwork.500v.mod8/tlbmlcol/hspice 
copying to 

/u/chip/proteus/celltest/ctgold.500v/tlbmlcol/hspice 
Compressing the hspice log in the gold directory 
/u/chip/proteus/celltest/ctgold. 500v/tlbmlcol/hspice 

Removing 

/u/chip/proteus/celltest/ctgold. 5 0 Ov/tlbmlcol/hspice/ tlbmlcol. trO 
Updating gold directory ctwork. 50 0v.mod8/tlbmlcol/verilog 
copying to 

/u/chip/proteus/celltest/ctgold. 500v/tlbralcol/verilog 
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From: 
Sent: 
To: 

Subject: 


ong (Warren R. Ong) 

Monday, November 28, 199411:48 AM 

'Geert Rosseel' 

Re: Touching Bases 


>From Geert Rosseel ... 

@ 

® Hi Warren, 
@ 

© Everything is going pretty weel here. I am still working on the ® top-level of Euterpe. 

It'll be a little while before we're done. 

@ I am definitelly noticing that there is one less engineer in the group. 

hromm. . . that could be good or bad. it's good (for you) if you've noticed you have less 
troubles and re-work. But, I'll take that in the positive sense. - Thanks! 

® I am looking forward to you back here. However, enjoy your time @ with the baby. You'll 
be very happy later you've taken the time off. 

® 

® We do have a working BJT, NMOS & PMOS. They are not perfect yet but ® the Guramel & I/V 
curves look pretty good. Al is going to start optimizing @ the devices now. Metal is also 
looking pretty good. 

If there is anyone who can tune the process, it has to be Al. 
This is encouraging news. 

Did anyone save me a glass of champagne? 

@ 

@ Have a Happy Thanksgiving ! ! ! 

Thanks, it was quite a meaningful day for me. It was my first one with my very own 
f amily i 


Warren, 
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Subject: 


From; 
Sent: 
To: 
Cc: 


torn (Tom Laidig) 

Monday, November 28, 1994 11:49 AM 
Tim B. Robinson' 

'geert (Geert Rosseel)'; 'wampler (Kurt Wampler)'; 'torn (Thomas Laidig)' 
Re: leafcell problem 


Tim B. Robinson writes: 

I 

1 1 have bee re-r\mning the make in the proteus snapshot to pick up some 

{changes in the latest BOM. 

I 

1 1 see the following which looks serious to me. Is this just one of the 
known failures? 


I*** gastatus detects error with vercon (see 
/ us r / t mp / 1 e a f rao Id . xbmuxf f b2 dhl 6 s ) 
Igmake [4] : *** 

[/n/auBpex/s23/euterpe-proteus-cp/compass/leaf /xbmuxf fb2dhl6s. ly] Error 1 

I 

Yup, that's one of the nasties. It's one that seems to work OK with the formula I haven't 
yet checked in, but sadly there are others that still fail. 


ooooO Ooooo 


\ ( tau ) / 
<_) (J 
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From: 
Sent: 
To: 

Subject: 


lisa 

Monday, November 28, 1994 1:41 PM 
'software-checkins-dist' 
gnu-tools/sim/terp memory. h memory. c 


Update of /p/cvsroot /gnu-tools/sim/terp 

In directory calliope: /N/auspex/root/se/lisa/src/gnu-tools/sim/terp 

Modified Files: 

memory. h memory. c 

Log Message : 

Record only a pointer to the reg_dep_t of the destination register, not to the whole 
reg_ptrs structure for this non-blocking load instruction. 

(When not executing out of the icache or ibuffer, the decoded instruction, containing the 
reg_ptrs structure, is temporary -- and thus not guaranteed to be around/ valid when the 
load completes . ) 
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From: 
Sent: 
To: 

Subject: 


lisa 

Monday, November 28, 1994 3:39 PM 
'software-checkins-dist" 
gnu-tools/slm/terp memory. h 


Update of /p/cvsroot/gnu-tools/sim/terp 

In directory calliope : /N/auspex/root/s6/lisa/src/gnu-tools/sira/terp 

Modified Files: 
memory . h 

Log Message: 

Use an unused memory space, not rom, for UV' s iincached memory space. 
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From: lisa 

Sent: Monday, November 28. 1994 3:42 PM 

To: 'rhunt' 

Subject: mmap problem 


I just checked- in a fix, but that won't show up until tonight's build. 
Until then, you can use '-lisa/bin/sgi5/terp, which has the fix in it. 

lisa 
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From: 
Sent: 
To: 

Subject: 


lisa 

Monday. November 28, 1994 4:34 PM 
'software-checkins-dist' 
gnu-tools/sim/terp stbio.c 


update of /p/cvsroot/gnu-tools/sim/terp 

In directory calliope: /N/auspex/root/s6/lisa/src/gnu- tools/ sim/terp 

Modified Files: 

stbio.c 
Log Message: 

Cover all threads with 0 to NUM_THREADS, not FIRST_G_thread to last_r_thread . 
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From: 
Sent: 
To: 

Subject: 


chip (Buffalo Chip) 

Monday, November 28, 1994 5:39 PM 
•geert' 

output of euterpe/verilog/bsrc/lt/.checkoutrc 


The output from euterpe/verilog/bsrc/lt/ . checkoutrc is 192k, so it is not included in this 
mail message. Instead, check the file 

/n/tmp/chiplog/geert . staypuf t . 14190 . euterpe-verilog-bsrc-lt 

(which is accessible from all machines) . This file will disappear in about 5 days. 
By the way, the exit status returned by .checkoutrc was 0. 
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FroiTi: 
Sent: 
To: 

Subject: 


michael (Chris Michael) 

Monday, November 28, 1994 6:23 PM 

'euterpe' 

CSM model update 


Design Folks, 

CSM has provided updated models for their foundry process. There are two significant 
changes (well, really there's only one) : 

1. Delta-W is reduced for PMOS . This affects narrow width PMOS devices. 

2. Models will allow simulations down to lj=0.45um, W=lum. However, minimum 
physical dimensions should still be L=0.6um, w=l.2um. The sub-minimum 
models are in place to aid in model smoothing. This shouldn't affect 
anything . 

As always, comments /suggest ions are welcome. 


Chris 
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From: 
Sent: 
To: 

Subject: 


chip (Buffalo Chip) 

Monday, November 28, 1994 6:48 PM 
'geert' 

output of euterpe/verliog/bsrc/ctiod/.checkoutrc 


The output from euterpe/verilog/bsrc/ctiod/ .checkoutrc is 160k, so it is not included in 
this mail message. Instead, check the file 

/n/tmp/chiplog/geert . staypuf t . 19444 .euterpe-verilog-bsrc-ctiod 

(which is accessible from all machines) . This file will disappear in about 5 days. 
By the way, the exit status returned by .checkoutrc was 0. 
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From: geert (Geert Rosseel) 

Sent: Monday, November 28, 1 994 7:29 PM 

To: 'biliz'; 'brianl'; 'dickson'; 'hopper*; 'mws'; 'tbr"; Vo'; 'woody' 

Subject: Euterpe placements 


Hi, 

These are the things we want to get done before 
rerunning the top-level placement of Euterpe ( 
planned for Wednesday). 


gf : create 20 atom gap and make two 64 bit sections. 
Rich 

rg : insert extra row in control section of 
block next to cr 

shift control of bypass section into gf 
Geert 

mc : create straight right edge in control 
section 
Hopper 

xlu : check in and release latest placement 
Tom 

nb : release in /u/chip and rebuild in snapshot 
Rebuild in snapshot is currently happening 

mst; limit right edge to less than 548. 
Rich 

cdio : distribute VREF generators on a byte-wide 

pitch 
Woody 

It : move section next to ctiod up such that it aligns 
with ctiod 
Woody 

iq, cp, cj, ctioi : placements of all 4 blocks 
Brianl 
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From: woody (Jay Tomlinson) 

Sent: Monday, November 28, 1 994 1 1 :42 PM 

To: 'doi'; 'lisar'; 'tbr'; 'torn'; 'chip' 

Cc: 'euterpe-checkins-disf 

Subject: Release of BOMs by woody (euterpe) 

PAGELIST: woody geert 

Checkin Message: 

aligned vref with data 

BOM Update in euterpe BOM 3.131 
BOM Update in euterpe/verilog BOM 3.95 
BOM Update in euterpe/verilog/bsrc BOM 184.2 
BOM Release in euterpe/verilog/bsrc/cdio BOM 36.0 
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From: 
Sent: 
To: 

Subject: 


hopper (Mark Hofmann) 

Tuesday, November 29, 1994 4:08 AM 

'geert (Geert Rosseel)' 

pager log message (fwd) 


Buffalo Chip writes: 

From chip®rhea Tue Nov 29 10:00:22 1994 
Date: Tue, 29 Nov 1994 10:00:13 -0800 
From: chip@rhea (Buffalo Chip) 

Message- Id: <199411291800 . KAA28639@rhea.microunity . com> 

To : hopper®rhea 

Subject: pager log message 

page from chip to hopper: 

Release euterpe/verilog/bsrc/mc BOM 45.0 initiated by hopper completed ® Tue Nov 29 
09:58:08 PST 1994 with exit Status 0.. chip 

all ports busy 

all ports busy 

all ports busy 

all ports busy 

all ports busy 

all ports busy 

all ports busy 

all ports busy 

all ports busy 

all ports busy 

all ports busy 


-thanks, 
hopper 


thanks, 
mark hofmann 
hopperOmicrounity . com 
408 734 8100 
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From: hopper (Mark Hofmann) 

Sent: Tuesday, November 29, 1 994 4: 1 9 AM 

To: 'Fred Obermeler* 

Cc: 'tbr (Tim B. Robinson)' 

Subject: Re: 1548/1548 

Fred Obermeier writes: 
The .checkoutrc does not run celltest since this is a very long running job. 
The proteus/leafgen/Makefile does have a do-celltest target that reruns all 
of the xb* leaf cells if they are out of date. Currently this target is 
only set up for the nominal condition. I'll need to change tiiis for 
rcdl, rcd5, rcd6, and rcd7. This increases celltest's disk space needs 
for /u/chip/proteus/ctgold.nom by a factor of 4. 
I don't think we have enough disk space for this yet. 
The Makefile will rerun celltest if any of the source flies change. 
Therefore, celltest will be rerun on all 1548 cells. However, if the 
ged21vs results (minus comments) are the same as previous runs, celltest 
will skip the cell and say that this cell has passed before. 

Fred. 

Okay. If we have disk space problems let's definitely make sure we have 
all circuits covered for rcd6. Then rcd7, then 5, then 1 . Disk space should 
not hold up these runs. 

Do you have an uptodate netlist of Euterpe for celltesting? 

What is the status there? 

thanks, 
-hopper 
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Subject: 


Sent: 

To: 

Cc: 


From: 


biliz (Bill Zuravleff) 

Tuesday, November 29, 1994 9:43 AM 
'euterpe' 

'billz (Bill ZuravlefO' 
Makefile woes 


Y'all, 


Help, I can't seem to size small pieces of my designs. 

This used to work! If I want to size via topt a portion of my design -- say just a pla 
-- using the /u/chip/proteus/Makef ile . def s and .rules, I could say "graake file. size" or 
more recently "gmake gards/f ile-passl . size" . 
Then, the following chain of rules are executed: 
.V (v2e) -> .v2e 
.v2e (emerge) .edif 
.edif (topt) -> .Stat 
.Stat (atoms) -> .size 


But this breaks almost immediately. The .v2e target rule is now in 
/u/chip/euterpe/verilog/bsrc/Makef ile . share as : 

$ (GARDS_DTR) /%.v2e: $ (GARDS_DIR) /% . v2e . conf ig vfiles 
# 

# Take a snooze to make sure vfiles looks older than the ,v2e file 

# when they are on different NFS file systems 
tt 

sleep 10 

$(V2E) -f vfiles -o $@ -c $ (GARDS_DIR) /$*.v2e.config -1 $ (GARDS_DIR> /$* . v2e . 
log $(LIB_DIRS) $(V2E_LIBS) 

But this uses "vfiles" as its argument and so v2e's my entire design, not just the file of 
interest . 

I don't see a .v2e target in the /u/chip/proteus/Makef ile . rules . 
(Possibly it got moved to Makefile . share?) 

Suggestions? 


Right? 


Thanks , 
billz 
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From: ken {Ken Hsieh) 

Sent: Tuesday, November 29, 1 994 1 1 : 12 AM 

To: 'tbr- 

Subject: Re: forwarded message from Charlie Root 
Tim, 

1 do not sure why Budtool reported this error message. 

The volume incr_3 was there smd used it to back up data successfully. 


Ken 

> From tbr Tue Nov 29 09:08:03 1994 

> Date: Tue, 29 Nov 1994 09:08:01 -0800 

> From: tbr (Tim B. Robinson) 

> To: ken 

> Subject: forwarded message from Charlie Root 

> Content-Ungth: 694 
> 

> Start of forwarded message 

> 

> What do these messages really mean? They seem to happen frequently: 

> 

> The BudTool Auto-Scheduler needs help. 
> 

> Not all of the volumes have been loaded into the 

> media server. 

> 

> Schedule: monday2-incr 

> Media Server: stackerO 

> Media Server Host: auspexO 
> 

> -Volumes Missing 

> incr_3 

> 

> -Volumes Found 

> incr_4 (*) 

> incr_5 (*) 

> incr_6 (*) 

> incr_7 (•) 
> 

> (*) With some media servers, such as stackers, 

> it is not possible to check all volumes. These 

> volumes are assumed to be in the media server. 
> 

> This backup is scheduled to begin 'Mon Nov 28 22:00:00 1994*. 
> 

> 

> End of forwarded message 

> 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Curtis Abbott [abbott@tallis] 

Tuesday, November 29, 1994 11:18 AM 

'Tom Eich' 

'Arya Behzad'; 'Graham Y. Mostyn'; 'hestia@ta(lis'; 'John Tang'; Tim B. Robinson' 
3/4 BTSC converter 


We have written software to do ch. 3/4 out. The current software is probably too simple, 
because it lacks filtering between video and audio, but even so it uses more cycles (over 
8% of Euterpe) than are available when we're doing mpeg. There should be plenty of cycles 
availcLble with analog video, so we can test it that way to verify and demonstrate 
functionality, but for a spin that goes into trials or something like that, we should 
definitely plan to add a can to the pcb. 


- Curtis 
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From: 
Sent: 
To: 

Subject: 


Buffalo Chip Ichip@rhea] 

Tuesday, November 29, 1994 11:42 AM 

'geert@rhea' 

pager log message 


page from chip to geert: 

Release euterpe/verilog/bsrc/cj BOM 77.0 initiated by brianl completed @ Tue Nov 29 
09:39:26 PST 1994 with exit status 0.. chip 

lock read: File exists 
all ports busy- 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
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From: Buffalo Chip [chip@rhea] 

Sent: Tuesday, November 29, 1 994 1 1 :59 AM 

To: 'geert@rhea' 

Subject: pager log message 


page from chip to geert : 

Release euterpe/verilog/bsrc/mc BOM 45.0 initiated by hopper completed ® Tue Nov 29 
09:58:08 PST 1994 with exit status 0.. chip 
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From: Eric Murray [ericm@MicroUnity.com] 
Sent: Tuesday, November 29, 1 994 12:05 PM 
To: 'Mark Hofmann' 
Cc: 'sysaclm@MicroUnity.com' 
Subject: Re: pager log message (fwd) 

Mark Hofmann wrote: 
> 

> BufTalo Chip writes: 

> From chip(@rhea Tue Nov 29 1 0:00:22 1 994 

> Date: Tue, 29 Nov 1994 10:00:13 -0800 

> From: chip@rhea (Buffalo Chip) 

> Message-Id: < 1994 1 1291 800.KAA28639@rhea.microunity.com> 

> To: hopper@riiea 

> Subject: pager log message 
> 

> page from chip to hopper: 

> Release euterpe/verilog/bsrc/mc BOM 45.0 initiated by hopper completed @ Tue Nov 29 09:58:08 PST 1994 with exit 
status 0.. chip 

> 

> all ports busy 

> all ports busy 

> all ports busy 

> all ports busy 

> all ports busy 

> all ports busy 

> all ports busy 

> all ports busy 

> all ports busy 

> all ports busy 

> all ports busy 
> 

> Is this a problem on our end? 
too many pages going out. 

when i wrote it i didn't think it'd be used as much as is is, so 
i didn't write a fency page queuing system. 

looks like I'll need to do so soon. 

in the mean time i can up the waiting period, that'll keep 

each paging process ttying longer. 


ericm ericm@microunity.com 
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From: 
Sent: 
To: 

Subject: 


Buffalo Chip [chip@rhea] 

Tuesday, November 29, 1994 12:05 PM 

'geert@rhea' 

pager log message 


page from chip to geert : 

Release euterpe/verilog/bsrc/ctioi BOM 12.0 initiated by brianl completed ® Tue Nov 29 
10:03:16 PST 1994 with exit status 0.. chip 

all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
all ports busy 
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From: tbr 

Sent: Tuesday, November 29, 1 994 1 2: 1 0 PM 

To: 'Curtis Abbott' 

Cc: 'Arya Behzad'; 'Graham Y. Mostyn'; 'hestia@tallis'; 'John Tang'; Tom Eich' 

Subject: 3/4 BTSC converter 
Follow Up Flag: Follow up 

Flag Status: Red 


Curtis Abbott wrote (on Tue Nov 29): 

We have written software to do ch. 3/4 out. The current software is 
probably too simple, because it lacks filtering between video and 
audio, but even so it uses more cycles (over 8% of Euterpe) than are 
available when we're doing mpeg. There should be plenty of cycles 
available with analog video, so we can test it that way to verify and 
demonstrate functionality, but for a spin that goes into trials or 
something like that, we should definitely plan to add a can to the 
pcb. 

Unless it is out long term plan to always use a can, I would advocate 
figuring out how to use an external converter of the type used with 
some cam-corders (craig has an example). Otherwise we may find 
oiu-selves having to enlarge the box again just to habndle a 
contingency. 

Tim 
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Subject: 


From: 


Sent: 

To: 

Cc; 


Tim B. Robinson [tbr@tallis] 

Tuesday, November 29, 1994 12:11 PIVI 

'Curtis Abbott' 

'Arya Behzad'; 'Graham Y. Mostyn'; 'hestia@tallis'; 'John Tang'; 'Tom Eich' 
3/4 BTSC converter 


Curtis Abbott wrote (on Tue Nov 29) : 

We have written software to do ch. 3/4 out. The current software is 
probably too simple, because it lacks filtering between video and 
audio, but even so it uses more cycles (over 8% of Euterpe) than are 
available when we ' re doing mpeg . There should be plenty of cycles 
available with analog video, so we can test it that way to verify and 
demonstrate functionality, but for a spin that goes into trials or 
something like that, we should definitely plein to add a can to the 
pcb. 

Unless it is out long term plan to always use a can, I would advocate figuring out how to 
use an external converter of the type used with some cam-corders (craig has an example) . 
Otherwise we may find ourselves having to enlarge the box again just to habndle a 
contingency. 


Tim 
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From: Graham Y. Mostyn Igraham@tallis] 

Sent: Tuesday, November 29, 1994 12:28 PM 

To: 'abbott@tallis'; 'tbr@tallis' 

Cc: 'arya@tallis'; 'graham@tallis'; 'hestja@talljs'; 'jt@tallis'; 'tbe@taltis' 

Subject: Re: 3/4 BTSC converter 


> From tbr®tallis Tue Nov 29 10:10:46 1994 

> Date: Tue, 29 Nov 1994 10:10:30 -0800 

> Prom: tbrOtallis (Tim B. Robinson) 

> To: abbott@tallis (Curtis Abbott} 

> Cc: arya®tallis (Arya Behzad) , grabam@tallis (Graham Y, Mostyn), 

hestia®tallis, 

> jt@tallis (John Tang), tbe®tallis (Tom Eich) 

> Subject: 3/4 BTSC converter 

> Content -Length: 827 


> Curtis Abbott wrote (on Tue Nov 29) : 

> 

> We have written software to do ch. 3/4 out. The current software is 

> probably too simple, because it lacks filtering between video and 

> audio, but even so it uses more cycles (over 8% of Euterpe) than are 

> available when we're doing mpeg. There should be plenty of cycles 

> available with analog video, so we can test it that way to verify and 

> demonstrate functionality, but for a spin that goes into trials or 

> something like that, we should definitely plan to add a can to the 

> pcb. 
> 

> Unless it is out long term plan to always use a can, I would advocate 

> figuring out how to use an external converter of the type used with 

> some cam-corders (craig has an example) . Otherwise we may find 

> ourselves having to enlarge the box again just to habndle a 

> contingency. 
> 

> Tim 

We are going to obtain some samples of modulators, and investigate this further. It is 
expected that several existing components will be ultimately dropped for volume 
production, allowing some space to be saved within the existing outline. 

Certainly this question does not affect our immediate plan to release the existing 
PCboard . 
Graham . 
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Subject: 


Sent: 

To: 

Cc: 


From: 


mws (Mark Semmelmeyer) 
Tuesday, November 29, 1994 1:34 PM 
'hopper'; 'brianC; 'geert'; 'billz'; 'woody' 
'ericm' 

Re: Returned mail: Cannot send message for 3 days 


> From Mailer-Daemon Tue Nov 29 11:30:00 1994 

> Date: Mon, 28 Nov 1994 17:19:51 -0800 

> From: Mailer-Daemon (Mail Delivery Subsystem) 

> Siibject: Returned mail: Cannot send message £or 3 days 

> Content -Length: 1517 
> 

> The original message was received at Fri, 25 Nov 1994 17:13:57 -0800 

> from mws®localhost 
> 

> The following addresses had delivery problems 

> billzogaea (unrecoverable error) 

> (expanded from: billz) 

> brianlOgaea (unrecoverable error) 

> (expanded from: brianl) 

> dicksonOdemeter (unrecoverable error) 

> (expanded from: dickson) 

> hopper@gaea (unrecoverable error) 

> (expanded from: hopper) 

> tbr®gaea (unrecoverable error) 

> (expanded from: tbr) 

> woody@gaea (unrecoverable error) 

> (expanded from: woody) 

> geert@ambiorix (unrecoverable error) 

> (expanded from: geert) 

> mws@gaea (unrecoverable error) 

> (expanded from: mws) 

> Transcript of session follows Message could not be 

> delivered for 3 days Message will be deleted from queue 
> 

5. Original message follows 

> Return- Path: <raws> 

> Received: from localhost by clyteranestra.microunity.com 
(8 . 6 .4/muse-sw. 3) 

> id RAA19350; Fri, 25 Nov 1994 17:13:57 -0800 

> Date: Fri, 25 Nov 1994 17:13:57 -0800 

> From: raws (Mark Semmelmeyer) 

> Message-Id: <1994112 60113 . RAA19350®clyteranestra .microunity. com> 

> To: billz, brianl, dickson, hopper, tbr, woody, geert 

> Subject: Re: Snapshot Status 

> Cc : mws 
> 

> I tried to update rgxmit_control .pim, but now the process seems to be 

> stuck looking for rgxmit-passl cell in 

> /u/chip/euterpe/compass/vlsi .boo-all . 
> 

> This was a painful procedure . Pim dependencies seem unenforced in the 

> makefiles and I couldn't find any leftover files saying what cells 

> were not placed. What is the better way to be doing this? 


> 


> 
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From: geert (Geert Rosseel) 

Sent: Tuesday, November 29, 1994 1:51 PM 

To: 'blllz'; 'briani'; 'geert'; 'hopper*; 'mws'; 'tbr*; 'vo'; 'woody* 

Subject: Euterpe snapshot 


Hi, 

Here is the state of the snapshot : 

BLOCK running STATUS BOM Who 
on 
machine 

EUTERPE : 183 . 0 

AU : FAILED TIMING 18.0 

AT : BAD PLACEMENT 24.0 

CC : BAD PLACEMENT 25.0 

CDIO : O.K. 36.0 

CJ : O.K. 77.0 

CK : O.K. 18.0 

CP : BAD PLACEMENT 21.0 Brian 

CTIOD : O.K. 14.0 

CTIOI : O.K. 12.0 

DR : O.K. 45.0 

DRIO : O.K. 10.0 

ES : FAILED TIMING 68.0 

GF : O.K. 21.0 

GT O.K. 57.0 

HC : BAD PLACEMENT 65.0 

HZ BAD PLACEMENT 9.0 

ICC : BAD PLACEMENT 9.0 

IFE : BAD PLACEMENT 9.0 

10 : O.K. 25.0 

IQ : tomato 45.0 

LT : ghidra 72.0 

MC O.K. 45.0 

MST O.K. 24.0 Rich 

NB : O.K. 86.0 

RG : tomato 86.0 

RGXMIT : BAD PLACEMENT 16.0 Hopper 

SR : O.K. 41.0 

UU : NO PLACEMENT 

XLU : staypuft 40.0 
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Subject: 


Sent: 

To: 

Cc: 


From: 


Curtis Abbott [abbott@tallis] 
Tuesday, November 29, 1994 2:05 PM 
Tim B. Robinson' 

'Aiya Behzad'; 'Graham Y. Mostyn'; 'hestia@ta!!js'; 'John Tang'; 'Tom Eich' 
3/4 BTSC converter 


Tim B. Robinson wrote (on Tue Nov 29) : 


Uliless it is out long term plan to always use a can, I would advocate 
figuring out how to use an external converter of the type used with 
some cam- corders (craig has an example) . Otherwise we may find 
ourselves having to enlarge the box again just to habndle a 
contingency . 


I believe it is rational to plan to always use a can for two reasons: 

(1) The RF modulate function is well defined, standardized, not subject to change, 
commoditized, and uses readily available analog signals. 

(2) The fully burdened cost (meaning including chip, chip packaging, power supply, heat 
sink, etc.) of the Euterpe cycles is much greater than that of the can. 

If Euterpe cycles were to become more numerous and 1/3 of their current cost, the second 
argument would be weakened, but the first would be as valid. 


Tim 


- Curtis 
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From: 
Sent: 
To: 

Subject: 


lisa 

Tuesday, November 29, 1994 2:62 PM 
'djc' 

Re: odd terp message 


> I get the following message - 
> 

> LISA: If etch from icache, *DIRECTLY* ! ? ! ? 
> 

> I have a program that is larger than will fit in the default ibuf so I 
run 

> terp with --ib 32k. I get this message when it do a 
> 

> blinki 0x800000c074b0 

Sorry, but I need more information, like a pointer to the executable. 

(That error is only supposed to occur when you are trying to fetch an instruction from a 
physical address beyond the end of the ibuffer. 

The code in the simulator looks fine, so I need something with which to debug it.) 


lisa 
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Subject: 


Sent: 

To: 

Cc: 


From: 


vanthof (vant) 

Tuesday, November 29, 1994 3:18 PM 
'dtacmo (Dominador Tacmo)'; Vikki (Vikki Vu)' 

'vanthof (Dave Van't Hof)'; 'hopper (Mark Hofmann)'; 'geert (Geert Rosseel)' 
all vdd extraction done 


vikki and Tacmo, 

I've finished the extraction of the vdd cif files and created the appropriate links in 
your compass /euterpe directories. If you 'notice' 
you 

local compass library or restart compass (on a large sparclO) , you should now see these 
files. 


Dave Van't Hof vanthof@microunity.com MicroUnity Systems Engineering, 
Inc . 

255 Caspian Way, Sunnyvale, CA (408) 734-8100 X2 76 # include <std_disclaim.h> Don't blame 
me, I didn't vote for him! 


Thanks , 
Dave 
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From: ras (Bob Sutherland) 

Sent: Tuesday, November 29, 1 994 3:32 PM 

To: 'Graham Y. Mostyn' 

Cc: 'pandora' 

Subject: Re: Digital video 

> 

> Bob, in discussing with various people the I/O required on Pandora for 

> software development, it seems useful to incorporate at least one 

> digital video input and perhaps an output. The data rate is 270 Mbit/s. 


I'm unclear as to the question, here. The output already runs at 
216MS/S, and the carrier can be set to zero. You then get video 
output at baseband. 

Then the next question is, why do we need 270MS/s at the input? If we 
interleave the I/Q streams we get the equivalent of 216 MS/ as is (if 
we set the carrier to zero). 

Who in the software area requested this? It would be easier if I 
could talk directly to him/her. 

> How could we best do this, assuming only metal changes on Calliope 

> and any reasonable amount of board design? Alan questions the idea of 

> direct interface to Euterpe to resolve bandwidth concerns, because that path 

> does not provide a buffer memory. 
> 

Neither of the above requires a metal change as far as I can tell, 

> If we don't require a qpsk receive fiinction, can we use that section, perhaps 

> oversampling the serial stream and avoiding the need for a PLL? 

> 

The qpsk receiver is a Ibit ADC sampled at 648 MS/s. I need to know 
more about the resolution requirement. 

> Any ideas? Thanks - Graham. 
> 

Lofs. Some are even useful :-). 


"NoINo!.. Don't pull on that., you never know what ifs attached to." 
RAS 
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From: ras (Bob Sutherland) 

Sent: Tuesday, November 29, 1994 3:54 PM 

To: 'Graham Y. Mostyn' 

Cc: 'pandora' 

Subject: Re: Digital video 

> 

> The digital video input that I was referring to is a purely digital 

> serial bit stream referred to as Dl (or D2). This has been set by 

> various world standards to carry 8 bit color video information. 

> The rate is fixed at 270Mbit/s. (I think you were thinking of analog video.) 
> 

Is this the CCIR-601 standard? 

And yes, I was thinking of analog video. 

> The context is that there would be a quantity of MPEG encoded video material 

> on disk, which would feed into the Pandora system via a suitable 

> digital I/O port. It would serve as source material for software developemnt 
> 

If the data stream is indeed serial (1-bit) the QPSK receiver can 

oversample the carrier (270MS/s) at 648MS/s and treat the serial bit 

as a symbol. The DDS in the QPSK then is set to rotate at some 

multiple of the the 270MS/s rate and the Integrate and Dump accumulator output 

can be used as an Early/Late PLL lock to the signal. Unfortunately, 

this may place quite a strain on Euterpe during acquisition, but it 

should take only a little attention to keep locked. 

As for the transmitter, we would probably have to build something in 
SOFA to generate the serial stream at 270MS/s. The only transmitter 
is clocked at 2 16MS/S. 


"No! No! ,. Don't pull on that., you never know what it's attached to." 
RAS 
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From: 
Sent: 
To: 

Subject: 


lisa 

Tuesday, November 29, 1994 4:13 PM 
'software-checklns-dist' 
gnu-tools/sim/terp memory.c 


Update of /p/cvsroot/gnu- tools/ sim/terp 

In directory calliope : /N/auspex/root/s6/lisa/src/giiu-tools/sim/terp 

Modified Files: 
memory , c 
Log Message: 

Only initialize rom, cerberus, and calliope if RUNNING_KERNEL . 
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From: 
Sent: 
To: 

Subject: 


lisa 

Tuesday, November 29, 1994 4:16 PM 
'software-checkins-dist' 
gnu-tools/sim/terp siminitc 


UpdAte of /p/cvsroot /gnu-tools/sim/terp 

In directory calliope : /N/auspex/root / s6 / 1 i sa/ src/ gnu- tools/sira/ 1 erp 

Modified Files: 
siminit .c 
Log Message: 

Better handling of zero-length (i.e. non-existant) special sections ( . onchip_text , .rom, 
etc . } in the executable being loaded . 
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From: 
Sent: 
To: 

Subject: 


lisa 

Tuesday, November 29, 1994 4:17 PM 
'software-checkins-dist' 
gnu-tools/sim/terp simgdb.c run.c 


update of /p/cvsroot/gnu-tcxjls/sim/terp 

In directory calliope : /N/auspex/root/s6/lisa/src/gnu-tools/siTn/terp 

Modified Files: 

simgdb.c riui.c 
Log Message: 

Modified both versions of sini_err() to call siin^doneO if sim__running, which will perform 
the necessary clean-up and longjmp to the "right" 

place . 
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From: 
Sent: 
To: 

Subject: 


lisa 

Tuesday, November 29, 1994 6:11 PM 

'software-checkins-dist' 

gnu-tools/si m/terp memory.c cerberus.c 


Update of /p/cvsroot/gnu-tools/sim/terp 

In directory calliope: /N/auspex/root/s6/lisa/src/gnu-toolB/sim/terp 

Modified Files: 

memory.c cerberus.c 
Log Message: 

X made a bad assumption in my previous modifications for enabling the caches, which was 
that memory-management would only be enabled when presently disabled. These changes cause 
subsequent (redundant) writes to the cerberus control register to be innocuous. 
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From: 
Sent: 
To: 

Subject: 


lisa 

Tuesday, November 29, 1994 6:21 PM 
'djc' 

Re: odd terp message 


> The test is . . . . /stb/stand/diag/metnlii/nb_2 . exe 
Thanks . 

I just checked- in some changes so that tomorrow's simulator should not have this problem. 
FYI -- Your test initializes cerberus register #6 (the control 

register) twice , which should not have caused a problem with the simulator, but it did. 
Nevertheless, I thought you might not be aware that the two memory- management enables 
(second one being 

redundant) were happening. One should be sufficient. ;-) 

Finally, if you have a test (such as this one, from what I can tell) which executes out of 
the buffer only, you should just initialize the cache szes to 0 when writing to the 
cerberus control register . 

Then you won't need the " - -ibuf f er-size 32k --dbuf f er- size 32k" 

on every invocation of terp, and the simulator won't have to allocate and initialize a 
bunch of cache data structures that will never even be used. 

Let me know if you have any more cache-related problems. 


lisa 
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From: 
Sent: 
To: 

Subject: 


briani (Brian Lee) 

Tuesday, November 29, 1994 8:44 PM 
'Geert Rosseel" 
Re: cp 


Geert Rosseel writes: 
Hi Brian, 

If you have problems placing cp because of I/O powers too large, why 
don't you force all i/O power levels to 2s . 

After it is all placed at the top-level, I can more accurately 
estimate the I/O power-levels. We can then do aonther iteration. 


OK. Good idea. I've done that and am releasing cp now. You are on the page list. It 
won't pass timing, but at least its placement should not conflict with the other sub- 
blocks. I think that it is still going to be difficult to make all these s\abblocks work. 

I will try a gmake brianl_euterpegards and see what happens. 


Geert 


Brian L. 
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From: paulb (Paul Berry) 

Sent: Wednesday, November 30, 1 994 1 2: 1 1 PM 

To: W 

Subject: Pandora notes 

Tve incorporated revisions you gave me regarding the Nov 17 
(marketing) meeting, but I still need your corrections to my fiizzy 
reporting of parts of the Nov 1 8 discussion that I wrote up 
as "data transfer between workstation and Hestia", 

I'll leave you a printout of the current set of notes, with a Postit 
yellow sticky on the part that needs your review. 

I will release the notes so they appear in /u/chip/pandora/doc/notes. 
(I'm finally getting to understand the 'make' and 'releasebom' procedures 
well enough to release things smoothly.) 

Bob Morgan has made progress in bringing up Frameviewer under 
the Mosaic web browser, and I think the Pandora notes will then 
be visible (in Frame format, not html) from within Mosaic. 

Policy question: 

I added the e-mail memo that Graham addressed to the group. 

I was thinking of also adding a reduced and edited summary of yesterday's 
flurry of discussion of digital video. 

But please confirm: are these mail discussions things that you would like 
to have incorporated into the notes file? (It seemed to me they were 
a continuation of the discussion by other means and therefore should be in, 
but one might argue that everyone concerned already has access to the mail, 
so that inserting summaries is redundant.) 
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From: 
Sent: 
To: 

Subject: 


Buffalo Chip [chip@rhea] 

Wednesday, November 30, 1994 12:30 PM 

'geert@rhea' 

pager log message 


page from chip to geert : 

Release euterpe/verilog/bsrc/iq BOM 46.0 initiated by brianl completed @ Wed Nov 30 
10:27:46 PST 1994 with exit status 1.. chip 

lock read: File exists 

all ports busy 

all ports busy 

all ports busy 

all ports busy 

all ports busy 

all ports busy 

all ports busy 

all ports busy 

all ports busy 

all ports busy 

all ports busy 
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From: paulb (Paul Berry) 

Sent: Wednesday, November 30, 1 994 12:55 PM 
To: 'tbr* 

Subject: Pandora specification 

I have put together a Frame document that is intended 
as a shell for a Pandora spec. 

At first I expected it would be a simple matter to just 
pull in fragments from existing documents. But I found 
it harder than I had expected to find appropriate material. 
The existing material was mostly architectural overview 
that really didn't say anything much about specs. So this is 
a VERY rough first cut 

What I have so far is in : 

~paulb/cvs/pandora/doc/spec/spec.book 
It has three chapers: 

Architecture 

Hardware 

Sottware 

The table of contents specTOC.doc ought to serve as an outline. 

Some of the things in there are copied from last January's 
draft of the Hestia spec, and are clearly incorrect here, but may 
serve as reminders that something like them is needed. 

In a product that gets much of its functionality 
from software, the "Software" section of the spec seems 
to me likely to be much larger than one would usually fmd 
in a more hardware-based product— but I haven't yet 
found material about the software a developer would need to 
use the testing and analysis ftmctions. Curtis suggests we 
break out two hardware and three software specs: 
Hardware: Euterpe 

Calliope 
Software Developers, 

Signal Generation, 

Testing/Characterization . 
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From: geert (Geert Rosseel) 

Sent: Wednesday, November 30, 1 994 2:33 PM 

To: 'billz'; 'briani'; 'dickson'; 'geert'; 'hopper*; 'mws'; tbr*; Vo'; 'woody' 

Subject: Euterpe snapshot 


Hi, 

New list of things to do. 
New top-level placement of Euterpe is 
planned for Friday 

As usual, if you release a BOM in /u/chip, please page me ( releasebom -P geert ) 


iq» cp, c j , ctioi i placements of all 4 blocks 

fix obstruction mask problem 

Briani 

cp : Check if power levels can be reduced 

Rich 

xlu : restore older version with control on 
both sides 
Tom Vo 

mst : reduce height with 5 rows 
Rich 

mc : shift control section by some number of 

atoms to the left. Tom Vo knows how much is 

allowed. 

Hopper 

cc : place 

xO = 1629 
yO = 404 

height < 82 rows 
Rich 

he : place 
Jay 

at : place 

xO = 480 

yO = 404 

height up to dcache 
width up to spar at left of GTLB 
Jay 

ioO : place 

xO = 160 
yO = 660 

height up to dcache 
Hopper 

nb : move to fill gap above xlu 

check for fan- out problems ( < 50ps margin paths) 
Geert 

dr : align right edge 

check for fan- out problems ( < 50ps margin paths) 
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Blllz 

ice : place 

xO = 2938 

1 spar- section wide. 

place under the iq, c j , cp, section such that 
the top of ice aligns with the bottom of the 
TBL, Icachae 
Hopper 

ife : size estimate 

Rich 

uu : size estimate 
Mark (S.) 

It : shift long narrow part to the right by 16 atoms, 
shorten the long row in the lower part of It. 
Jay 

hz : place 

xO = 2938 
yO = 527 

one spar- section wide 
Rich 
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From: paulb (Paul Berry) 

Sent: Wednesday, November 30, 1 994 3: 1 3 PM 

To: 'tbr' 

Subject: Euterpe and Calliope spec sheets 

In Mouss' lunchtime talk, he mentioned that he had 
"sent the spec sheets for Euterpe and Calliope" 
to PictureTel. 

What did he send them? Can I use whatever it was 
as a prototype? 
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Subject: 


Sent: 

To: 

Cc: 


From: 


doi (Derek Iverson) 

Wednesday, November 30, 1994 8:00 PM 

'jeffm'; 'guarino'; 'gmo'; 'sandeep'; 'gregg'; 'wayne'; 'iimura'; 'doi' 

'hestia' 

Software Bring-up Ideating - November 30, 1994 


Software Bringup Meeting 


November 30, 1994 


Next Meeting: 


December 7 at 10:00 am. 


Attendees: jeffm, guarino, gmo, gregg, doi, sandeep 


New Action Items 


Item: Define and implement a snapshot environment for the HW and SW 

simulators . 
Who: jeffm, gmo 
Status: [11/30] new. 

Jeff is going to start the process off with an e-mail message 
summarizing the current thoughts on the subject. 

Item: Get the cycle count for oc-mem test that ran on the hardware 

simulator . 
Who : doi 

Status: [11/30] new. 

Derek will asJc lisar if the data is still around. 


Review of Action Items 


Item: What is dependent on SC within Euterpe? ROM & LEDs? 

Reads of cerberus registers? 
Who : wayne 

Status: [11/23] No progress. 

Item: Continue trying to find either source code for parallel drivers 

or descriptions of hardware so we can write out own. 
Who: gmo sgi machines 
Who : doi sun machines 

Who: wayne HPIB driver source or HW desc. for either Sun or SGI, 
Status: [11/23] progress continues. 

We are no longer a Sun Catalyst member. 

Out SGI Systems Integrator is going to investigate what 
it would take to become a SGI developer (like Catalyst) to 
see if that would get us the support (info) we need. 


Item: Implement parallel port device drivers for sun and sgi. 
Who: sandeep, doi 

Status: on hold pending discussion of CBI at the Pandora Meeting (11/18) 

Jerry K. found a driver on the Linux machine that appeared 
to handle interrupt based transactions. 
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On achilles (if you have an id on the machine) you can see 
the code on /usr/src/linux/drivers/net/plipc . 


Item: Build scripting/Ul capabilities above gdb for regression tests. 
Who : doi 

Status: on hold until the the boot, gdb boot stub, and virtual devices 

are complete, (estimated start date of 12/23) 

Item: Create performance test plan 

Who: jeffm, guarino 

Status: [11/30] no progress 

Item: Add Unix- like tests to software acceptance tests. 
Who: iimura 

Status: [11/3 0] no progress 

Item: CerbROM support from terp. 
Who : gmo , sandeep 
Status : Done . 

Item: Simulator needs to understand ""reset" 
Who : gmo 

Status: [11/30] not started (due 12/23) 

Item: Implement and bring-up boot, gdb boot stub, and virtual device 

support on the software simulator. 
Who : sandeep/gmo 

Status: in progress (due 12/23) 


General Discussion 


Jef fm gave a short summary of what is left to be developed for Euterpe and his estimate of 
order . 

nb anit-use 
load use stuff 
uncached execution 
sync ops 

We also decided to start tracking the progress of running tests on the hardware simulator 
in this meeting. 
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From: tbe@MicroUnity.com 

Sent: Wednesday, November 30, 1994 10:45 PM 

To: 'abbott@MicroUnjty.com' 

Cc: •tbr@MlcroUnity.com'; 'arya@MicroUnlty.com'; 'graliam@MicroUnity.com'; 

'hestia@MicroUnity.com'; 'jt@MicroUni1y.com' 
Subject: Re: 3/4 BTSC converter 


On November 29, Curtis Abbott wrote: 
>Tira B. Robinson wrote (on Tue Nov 29) : 


> Unless it is out long term plan to always use a can, I would advocate 

> figuring out how to use an external converter of the type used with 

> some cam-corders (craig has an example) . Otherwise we may find 

> ourselves having to enlarge the box again just to habndle a 

> contingency. 
> 

> Tim 
> 

>I believe it is rational to plan to always use a can for two reasons: 
>{l) The RF modulate function is well defined, standardized, not subject 

>to change, coraraoditized, and uses readily available analog signals. 
>(2) The fully burdened cost (meaning including chip, chip packaging, 
>power supply, heat sink, etc.) of the Euterpe cycles is much greater 
>than that of the can. 
> 

>if Euterpe cycles were to become more numerous and 1/3 of their current 
>cost, the second argument would be weakened, but the first would be as 
>valid. 
> 

>- Curtis 

I agree with your reasons, and add further (based upon our brief conversation today) that 
whether or not Hestia is first deployed for analog or digital conversion, the space and 
provisions for a 3/4 BTSC converter in a can should be in the design, for reasons of 
upgradability and completeness. 

Therefore I will file a tkgnat on this and look for the results of the converter can 
survey Graham mentioned for the next revision of the pcb. In fact, I'd like to get my 2 
cents in on the physical parameters of such a can. I'm concerned about fitting it in 
based on particular physical constraints such as at the rear panel more than on total pcb 
area . 

-Tom 


Tom Eich 

MicroUnity Systems Engineering, Inc. 
255 Caspian Dr, Sunnyvale, CA 94 08 9 
(408)734-8100, (408)734-8136 fax 


tbe®microunity . com 
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